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4.1. Noţiunea de interfeță grafică utilizator 


Noţiunea de interfaţă poate fi definită ca o graniţă de-a lungul căreia două 
sisteme independente se întâlnesc şi comunică între ele. În domeniul 
tehnologiei informaţiei există trei tipuri de interfeţe: 

- Interfețe-utilizator - ansamblul de echipamente şi programe care oferă 

utilizatorilor posibilitatea de a interacţiona cu o aplicaţie; Pot fi: 
„ interfeţe grafice 
= Interfeţe bazate pe comenzi introduse de la tastatură 


- interfețe-software - ansamblul de programe specializate pe care 
aplicaţiile le utilizează pentru a comunica unele cu altele; 

-  interfețe-hardware - ansamblul de instrumente pe care dispozitivele 
hardware le utilizează pentru a comunica unele cu altele 


În general, o interfaţă grafică utilizator se obţine prin integrarea mai multor 
elemente prin care se asigură reprezentarea grafică a programelor, datelor şi a 
opţiunilor pe care le va avea utilizatorul la un moment dat. O interfaţă grafică 
încearcă să ofere utilizatorilor aplicaţiei şi mijloacele necesare pentru ca ei să 
facă ceea ce vor şi nu să le arate o listă cu ce poate calculatorul să facă. 

lată o listă a caracteristicilor pe care trebuie să le regăsim la o GUI (Graphical 
User Interface): 


foloseşte un afişaj "hartă de biţi", de înaltă rezoluţie; 

utilizează un echipament de indicare (de regulă, mouse); 

oferă o reprezentare vizuală a textelor şi a altor elemente grafice aşa cum 
apar la tipărire (WYSIWYG-What You See Is What You Get); 

respectă paradigma de interacţiune obiect-acţiune; 

permite transferul de informaţii între programe; 

permite manipularea directă a obiectelor şi informaţiilor de pe ecran; 
oferă elemente de interfaţă standard, cum ar fi meniurile,sau ferestrele de 
dialog ; 

asigură reprezentarea vizuală a obiectelor pe ecran (ferestre şi icon-uri); 
asigură feed-back vizual la acţiunile utilizatorului; 

reprezintă vizual acţiunile şi operaţiunile posibile (în meniuri, bare de 
instrumente, butoane de comandă); 

asigură preluarea opţiunilor şi şi a caracterelor introduse de la 
tastatură de către utilizator, prin intermediul unor componente grafice 
standard (căsuțe de text, liste, butoane de opţiune(checkbox) ; 

permite utilizatorului să personalizeze interfaţa şi interacţiunile; 

asigură utilizatorului libertatea de opţiune de a utiliza tastatura sau alte 
echipamente de intrare, după dorinţă şi obişnuinţă. 


Multe dintre interfețele grafice pe care le utilizăm, între care şi Windows, 
întrunesc doar o parte din aceste caracteristici sau pe toate. 


1 Microsoft Corporation, The Windows Interface Guidelines for Software Design, Microsoft Press, 1995 


La modul cel mai simplu, o interfaţă grafică este definită prin WIMP - Windows, 
Icons, Menus and Pointing device - acel tip de interfaţă-utilizator inventat şi 
popularizat cu succes de Macintosh în 1970 şi imitat ulterior de sistemele Windows). 
Acest gen de interfaţă grafică se distinge prin faptul că pe ecran apar ferestre, icon- 
uri şi meniuri şi există un mouse pentru exploatarea acestora. În proiectarea unei 
GUI, este esenţial ca utilizatorul să vadă pe ecran obiectele pe care le-a definit 
exact aşa cum arată ele şi cum se vor obţine pe hârtie dacă sunt tipărite. 

O altă caracteristică fundamentală a IGU este asigurată de manipularea directă 
de către utilizator a obiectelor şi informaţiilor de pe ecran. Prezentarea grafică a 
componentelor nu este suficientă ca să dispunem de o interfaţă grafică. Un icon 
constituie o reprezentare grafică pentru un obiect, dar dacă utilizatorul nu poate 
decât să se uite la el, atunci nu avem în faţă o interfaţă grafică. Manipularea 
directă îmbracă mai multe forme, în majoritatea cazurilor fiind vorba de un click 
de mouse (apăsarea unui buton, selecţia unei opţiuni dintr-o listă sau „bifarea” 
unui checkbox), şi constituie unul dintre aspectele cheie ale GUI. 

Am menţionat între caracteristicile GUI şi utilizarea controalelor grafice. Este 
vorba despre acele componente ale interfeţei prin care utilizatorul alege, introduce 
date, iniţiază acţiuni sau navighează prin interfaţa aplicaţiei. Se încadrează aici 
controale simple, precum casete de validare (checkbox), casete de text (textbox), 
butoane de comandă sau liste, dar şi containere sau casete de dialog(forms) care 
reunesc mai multe controale simple. Includerea acestor controale în interfaţă 
ţine seama de modelul utilizatorului şi de metaforele comune, cunoscute acestuia. 
Se urmăreşte de asemenea utilizarea similară a acestor controale cu alte aplicaţii sau 
medii de lucru familiare utilizatorilor sau recomandate de standarde. De fapt, 
standardele recomandă utilizarea acelor controale care valorifică experienţa 
utilizatorilor şi foloseşte memoria asociativă a acestora. 


4.1.1. Principii de urmat în dezvoltarea interfeţelor grafice 


O interfaţă grafică bine proiectată trebuie să respecte următoarele principii:: 
- controlul aplicaţiei de către utilizator; 
- manipularea directă a informaţiilor; 
- consistență; 
- toleranţă la greşelile utilizatorului; 
- asocierea de "replici" pentru comenzile unei aplicaţii; 
- estetică; 
- claritate; 
- simplitate. 


2 Principii de proiectare a interfeţelor grafice utilizator, în PC Report, nr. 51/1996, p. 26 


Controlul aplicaţiei de către utilizator 

Conform primului principiu enunțat, este foarte important ca utilizatorul să simtă 
că el este cel care controlează aplicaţia şi nu invers, în ai doilea rând, utilizatorul 
trebuie să aibă posibilitatea să personalizeze mediul de iucru, conform preferințelor 
sale. Utilizatorul trebuie să fie acela care iniţiază acţiunile; ei trebuie să aibă un rol 
activ şi nu reactiv. Există şi procese care pot fi automatizate, dar derularea lor 
trebuie să se facă sub controlul utilizatorului (la apariţia unor cazuri 
excepţionale utilizatorul trebuie să decidă acţiunea ce va fi executată). Pentru a 
putea răspunde acestui principiu aplicaţia trebuie: 

(a)să fie interactivă (trebuie să ofere întotdeuana un rezultat vizual în urma 
unei acţiuni a utilizatorului) 

(b)să răspundă la fiecare acţiune a utilizatorului 

(c)să fie flexibilă. 

Manipularea directă a informaţiilor 

Conform acestui principiu, utilizatorul trebuie să poată manipula informaţiile întro 
manieră familiară, indiferent de modul în care acestea sunt reprezentate intern la 
nivelul soft-ului-applicaţie. Astfel, utilizatorul poate constata direct relaţia cauză- 
efect între acţiunea sa efectuată prin intermediul interfeţei şi rezultatul acesteia 
(modul în care programul reacţionează la acţiunea sa). Fie că mută un obiect sau se 
deplasează în cadrul unui document, utilizatorul trebuie să vadă modul în care 
acţiunea sa afectează obiectele existente pe ecran. Vizibilitatea informaţiilor şi a 
opţiunilor reduc supraîncărcarea mentală a utilizatorilor. Pentru satisfacerea 
acestei cerinţe, interfaţa trebuie să ofere utilizatorului o manieră directă şi intuitivă 
de operare. 

Utilizatorii recunosc mai uşor o comandă sau un instrument de lucru dacă le 
asociază cu o imagine sau un simbol. De aceea, în cadrul interfeţelor grafice se 
utilizează metaforele. Acestea facilitează învăţarea şi exploatarea unei aplicaţii, 
permiţând utilizatorilor să-şi transfere cunoştinţele şi experienţa. Metaforele sunt 
deosebit de utile, deoarece utilizatorii rețin mai uşor un înţeles sau o semnificaţie 
ataşate unui obiect familiar, decât ar reţine numele unei comenzi. Când se 
utilizează o metaforă, nu este neapărat necesar ca implementarea în cadrul 
aplicaţiei să fie limitată de corespondentul său din lumea reală. De exemplu, un 
folder (dosar) din Windows, spre deosebire de corespondentul său real, poate 
organiza nu doar documente sau aplicaţii, ci şi echipamente (calculatoare, 
imprimante) sau alte foldere. Motivul folosirii metaforelor într-o interfaţă este 
construirea unui "pod cognitiv”. 

Consistenţa 


Principiul consistenţei cere ca interfaţa să fie familiară şi predictibilă, oferind 
utilizatorului sentimentul de stabilitate. Astfel, indiferent de opţiunile pe care le 
selectează la un moment dat, rezultatul obţinut (o fereastră sau un mesaj de 
atenţionare) trebuie să furnizeze o reprezentare grafică familiară, cu care 
utilizatorul s-a obişnuit deja în cadrul activităţilor zilnice pe care le desfăşoară. 
Consistenţa permite utilizatorilor să transfere cunoştinţele existente în procese noi 
şi să înveţe mai rapid aplicaţiile noi. Consistenţa este citată ca fiind cea mai 
importantă în obţinerea unei interfeţe de calitate. Dacă este asigurată, consistenţa 
îl va sprijini pe utilizator în a-şi construi un model mental adecvat al modului de 
funcţionare al aplicaţiei, ceea ce înseamnă costuri de instruire şi suport post- 
instalare mai scăzute. 

lată câteva obiective pe care programatorul trebuie să le urmărească în 
dezvoltarea interfeţelor grafice pentru a asigura consistenţă la nivelul aplicaţiei: 

- un dublu clic într-o listă anume, poate declanşa o anumită acţiune. Ar fi de 
dorit să se producă aceeaşi acţiune (un acelaşi tip de rezultat) atunci când 
se efectuează dublu clic într-o altă listă din aplicaţie. 

- Butoanele trebuie plasate în locuri "strategice", locuri ce trebuiesc 
păstrate pe parcursul tuturor formularelor aplicaţiei 

- Textul, sau imaginea, afişată de butoane trebuie să fie acelaşi pentru 
butoanele care produc rezultate similare (adăugarea unor date noi, salvarea 
datelor modificate, etc.) 

- Organizarea componentelor de editare a datelor (căsuțe de text, liste de 
opţiuni) trebuie să fie aceeaşi în toate ferestrele ce furnizează acces la 
date. 

- Schema de culori utilizată trebuie să fie şi ea consistentă (dacă utilizăm 
aceeaşi culoare pentru două obiecte, între ele ar trebui să existe o legătură 
). 

Consistenţa trebuie asigurată în toate aspectele interfeței: 

- numele comenzilor - comenzi similare în aplicații diferite să aibă acelaşi 
nume, pentru a folosi cunoştinţele pe care le au utilizatorii de la 
aplicațiile precedente (majoritatea aplicațiilor folosesc 
pentru deschiderea unui fişier comanda Open); 

- prezentarea vizuală a aplicaţiei - comenzile similare din aplicaţii diferite 
trebuie să fie apelabile prin aceleaşi elemente vizuale (de exemplu, 
salvarea unui fişier se face în majoritat:ea aplicaţiilor prin clic pe butonul 
care are stilizată o dischetă); 

- comportamentul operațional al aplicației - operaţiile similare trebuie să 
aibă o interfaţă vizuală identică sau măcar asemănătoare, iar cererea de 


informaţii suplimentare pentru realizarea unei operaţiuni trebuie făcută 
utilizând elemente de interfaţă comune operaţiunilor (de exemplu, 
operaţiunile de acces la fişiere - citire sau salvare - ar trebui să 
deschidă casete de dialog asemănătoare). 

Pentru asigurarea consistenţei trebuie avute în vedere următoarele aspecte ale 
acesteia: 

- consistenţa în cadrul aplicaţiei. Prezentarea funcţiilor comune 
trebuie să se facă folosind un ansamblu consistent de comenzi şi/sau 
interfeţe vizuale. Implementarea unei comenzi "copy" care într-un caz 
generează o operaţie imediată, iar în alt caz afişează o fereastă de 
dialog pentru introducerea unei destinaţii este un exemplu de 
inconsistenţă. Proiectantul trebuie să folosească aceleaşi comenzi pentru 
operaţii care utilizatorului îi par similare din punct de vedere al 
funcţionalităţii. Versiunile noi ale aplicaţiei, îmbogăţite funcţional, nu 
trebuie să modifice maniera de lucru anterior adoptată. 

- consistenţa cu mediul de operare - menţinerea unui grad ridicat de 
consistenţă cu convențiile de interacţiune şi interfaţă furnizate de 
sistemul de operare va asigura exploatarea mai facilă a aplicaţiei, 
utilizatorul fiind deja familiarizat cu acestea. Orice nouă aplicaţie 
destinată unui sistem de operare trebuie să se alinieze la standardele pe 
care acesta le impune, iar efectul acestei constrângeri nu poate fi decât 
benefic, facilitând însuşirea mai rapidă a noului produs. 

- consistenţa cu metaforele utilizate. Se recomandă menţinerea 
metaforelor cu care utilizatorul este deja familiarizat şi alegerea cu grijă a 
metaforelor noi. Adesea, dacă un comportament particular nu poate fi 
asociat unui obiect aşa cum reiese din metafora definită, utilizatorul are 
dificultăţi în realizarea unei asocieri între comportament şi obiect. 

Prin respectarea acestui principiu se obţine ceea se numeşte stabilitate - 
interfaţa este familiară (chiar dacă e vorba de o aplicaţie nouă), iar răspunsul 
aplicaţiei este previzibil (se mizează pe comportamentul similar al aplicaţiilor). 

Toleranţa la erori 

Toleranţa este necesară datorită comportamentului utilizatorilor, care sunt în 
definitiv simpli oameni, supuşi greşelilor. Cel mai la îndemână exemplu este 
ştergerea unui fişier, efectuată din greşeală, fiind grăbiţi, obosiţi sau neatenţi. O 
astfel de eroare are un impact puternic asupra moralului utilizatorului, mai ales 
când nu există o modalitate de recuperare sau aceasta este dificil de identificat. 
Impunerea acestui principiu pleacă deci de la premiza că utilizatorul obişnuit face 
frecvent greşeli, atât fizice (cum ar fi apăsarea accidentală a unei taste), cât şi de 


logică. O interfaţă bine proiectată trebuie să înţeleagă gama de erori potenţiale pe 
care utilizatorui poate să le comită şi să aibă prevăzute posibilităţi de ieşire din 
astfel de situaţii şi de recuperare a eventualelor pierderi. 

Un alt aspect deosebit de important în cadrul acestui principiu se referă la 
maniera de atenţionare a utilizatorului asupra apariţiei unei erori sau asupra riscului 
unei anumite operaţii. Mesajele furnizate în această situaţie trebuie să descrie 
succint şi concis problema, astfel încât utilizatorul să înţeleagă sursa erorii sau riscul 
la care se poate aştepta în cazul continuării unei peraţii (de obicei este vorba de 
operaţiile de ştergere şi modificare a datelor preluate deja la nivelul aplicaţiei) 

Spre exemplu, să discutăm despre butoanele predefinite sau combinaţiile de taste 
pentru anumite comenzi(cunoscute sub numele de „shortcut”). De regulă, fiecare 
ecran sau casetă de dialog are un buton de comandă predefinit, care este invocat 
atunci când utilizatorul apasă tasta Enter şi pentru fiecare buton de acţiune există 
şi o combinaţie de taste ce poate fi utilizată în lolocul mouse-ului. Riscul este ca 
utilizatorul să apese involuntar tasta Enter, lansând astfel comanda ataşată 
butonului implicit, sau o combinaţie de taste validă care dfeclanşează comanda 
asociată unui anumit buton. În aceste cazuri este esenţial un mesaj de avertizare 
(în special pentru operaţiile distructive). 

În plus, utilizatorii sunt adesea tentaţi să exploreze o interfaţă, prin 
selectarea "oarbă" şi "la întâmplare" a comenzilor şi opţiunilor unei aplicaţii, în 
acest fel utilizatorii îşi însuşesc modul de exploatare al unei aplicaţii - este metoda 
numită "încercare şi eroare" sau învăţarea prin descoperire. O interfaţă bine 
proiectată permite descoperirea interactivă a modului de exploatare a! unei 
aplicaţii. Prevenirea distrugerii datelor sau a blocării sistemului trebuie asigurată 
prin mesaje de avertizare în situaţiile în care starea aplicaţiei sau datele cu care 
operează aceasta se pot deteriora şi prin reversibilitatea unor acţiuni (posibilităţi de 
anulare sau de recuperare a datelor ) 

Dacă la un moment dat, într-un anume context, o opţiune sau un submeniu nu se 
pot utiliza, cel mai bine este să indicăm cumva indisponibilitatea, într-un mod 
distinct faţă de opţiunile disponibile (printr-o proprietate de tip Grayeg, care lasă 
opţiunea vizibilă, dar nu permite selectarea ei) şi nu să le ascundem. Ascunderea 
componentelor îl poate bulversa pe utilizator, care încearcă să-şi construiască un 
model menta! al funcţionării aplicaţiei. 

Asocierea de "replici" pentru comenzile unei aplicaţii 

Conform acestui principiu, o interfaţă este bine să transmită câte o replică sau un 
răspuns pentru fiecare acţiune a utilizatorului. Această cerinţă contribuie şi ea la 
sporirea confortului utilizatorului şi ea impune ca aplicaţia să confirme (prin replici) 
că a preluat cererea utilizatorului şi că este în curs execuţia acţiunii aferente cererii. 


Replicile pot fi vizuale sau auditive şi trebuie să confirme utilizatorului că aplicaţia 
răspunde într-adevăr la acţiunile sale. Aceste replici trebuie să apară în timp real, 
adică concomitent cu desfăşurarea operaţiei cerute. Puţini utilizatori (în fapt, cei 
avizaţi şi experimentați) rămân indiferenți în faţa unui ecran care nu afişează nici 
un mesaj şi care nu reacţionează în nici un fel dacă prelucrarea ce se execută la 
momentul respectiv durează ceva mai mult timp. Când este vorba de acţiuni de 
durată mai mare, replica ce trebuie afişată trebuie să precizeze: starea (derularea) 
acţiunii în curs (de obicei cu exprimare în procente sau în secunde ce au rămas), 
precum şi modul în care acţiunea poate fi suspendată sau anulată. Există două 
posibilităţi de informare a utilizatorului asupra acţiunii pe care aplicaţia o execută la 
un moment dat: 

- prin actualizarea liniei de stare (linia care apare în partea inferioară a 
ferestrei principale); 

- prin afişarea de casete de mesaj. 

Atunci când informaţia ce trebuie afişată este redusă ca dimensiuni, linia de stare 
a aplicaţiei este suficientă pentru afişarea de mesaje. Dacă însă este nevoie de 
afişarea unui mesaj mai amplu şi dacă particularităţile acţiunii în curs permit 
întreruperea şi/sau abandonarea acesteia, atunci se recomandă să se recurgă la o 
casetă de dialog non-modală care să cuprindă atât informaţiile, cât şi butoanele 
corespunzătoare acţiunilor de întrerupere sau terminare a acţiunii în curs. 

© Estetica 

Principiul acesta se referă la proiectarea elementelor vizuale. Interfața trebuie 
să atragă utilizatorul; un mediu de lucru plăcut, prietenos contribuie la confortul 
utilizatorului şi la o mai bună înţelegere a informaţiei prezentate. Atributele 
vizuale furnizează date preţioase şi comunică informaţii importante cu privire la 
comportamentul diferitelor obiecte. O recomandare care decurge din aplicarea 
acestui principiu este implicarea utilizatorului în proiectarea interfeţei. De multe ori, 
lucruri care par evidente pentru proiectant sunt pentru utilizatorul de rând neclare 
sau ambigue. 

Următoarele aspecte detaliază principiul esteticii: 

- utilizarea corespunzătoare a culorilor. Un prim aspect se referă la 
folosirea aceleaşi scheme de culori în toate ecranele aplicaţiei. Apoi, 
trebuie respectată regula contrastului (culoare închisă pe fond deschis sau 
culoare deschisă pe fond închis), astfel încât ecranele să fie citibile. O 
combinaţie roşu-albastru este foarte frumoasă, dar absenţa contrastului 
poate crea probleme de urmărire a textului pe ecran. In fine, se alege 
uneori o anume culoare pentru a scoate în evidenţă o opţiune sau o 
situaţie deosebită, întrucât nu toţi utilizatorii reacţionează la culori, se 


recomandă folosirea şi a unui indicator secundar (un simbol deosebit sau un 
semnal sonor). 

- folosirea de fonturi adecvate - este vorba aici de fonturi uşor de citit 
(spre xemplu, Times New Roman în loc de Comic Sans MS). De asemenea, 
atenţie la numărul de fonturi ce se folosesc pe acelaşi ecran - în nici un 
caz mai mult de trei. Se pot obţine efecte diferite prin folosirea de 
atribute (bold, italic, umbrit) pentru acelaşi font. 

- alinierea câmpurilor şi datelor propriu-zise. Datele se aliniază 
corespunzător tipului lor astfel: şirurile la stânga, datele numerice întregi la 
dreapta, iar cele numerice reale se aliniază după marca zecimală, datele 
calendaristice tot la dreapta. 

Claritatea 

Principiul clarităţii poate fi discutat din 3 puncte de vedere: vizual, 
conceptual, lingvistic. 

Claritatea vizuală este asigurată de elementele vizuale (obiectele) care o 
compun. Acestea trebuie să fie sugestive, uşor de înţeles, ele reprezentând în fapt o 
transpunere simplificată a unor obiecte reale. De asemenea, este importantă şi 
aranjarea obiectelor pe ecran. Opțiunile sau comenzile care se grupează din punct 
de vedere logic trebuie reunite şi delimitate de celelalte prin chenare sau cadre, în 
mod simiiar, trebuie plasate separat şi delimitate între ele opţiunile între care nu 
există legătură. 

Claritatea conceptuală se caracterizează prin două atribute: simplu şi realist! 
Simplitatea interfeţei înseamnă afişarea unui număr rezonabil de obiecte pe ecran 
(într-o fereastră), iar caracterul realist este asigurat prin similitudinea cu obiectele 
reale (de exemplu, dacă o fereastră prezintă o factură, este de dorit ca obiectele 
care o descriu să reproducă cât se poate de exact aspectul acesteia). 

Claritatea lingvistică se referă la textul ce apare în interfaţă. Denumirile 
opţiunilor de meniu, mesajele, opţiunile, etc. trebuie să fie clare, neambigue. 
Textul pe care îl afişăm pe ecran este o sursă principală de informare a utilizatorilor, 
de aceea ar trebui să se utilizeze cuvinte sau propoziţii întregi, nu prescurtări. Mesajele 
trebuie să fie formulate categoric şi fără ambiguităţi. Spre exemplu, la operaţiunea de 
introducere a codului clientului, dintre următoarele două mesaje "Lungimea codului de 
client este de 5 caractere!", "Aţi introdus o valoare eronată!" ar trebui utilizat primul, 
altfel utilizatorul va fi derutat, pentru că nu are cum să intuiască ce anume se doreşte 
de la el. 

Simplitate 

O interfaţă trebuie să fie simplă, uşor de învăţat şi exploatat. Ea trebuie să 
permită accesul facil la toate funcţionalităţile oferite de aplicaţie. Este recomandată 


reducerea informaţiilor prezentate în interfaţă la strictul necesar unei comunicări 
eficiente (trebuie evitate descrierile detaliate, frazele stufoase sau irelevante). 
Importantă este şi aranjarea şi prezentarea elementelor interfeţei (se vor folosi 
semantici şi ordini de reprezentare naturale). 

Maximizarea funcţionalităţii unei aplicaţii intră în contradicţie cu simplitatea 
cerută, dar cele două aspecte pot fi echilibrate printr-o proiectare corespunzătoare. 

O metodă recomandată, mai ales pentru aplicaţiile cu grad mare de 
complexitate, este metoda descoperirii progresive. Această metodă se bazează pe 
două aspecte: 

- organizarea atentă a informaţiilor, evitând aglomerarea pe un singur ecran; 

- prezentarea fiecărei informaţii la momentul potrivit - atunci când nu 
este nevoie de ea, informaţia se ascunde. “"Ascunderea" datelor reduce 
cantitatea de informaţii cu care utilizatorul vine în contact la un moment 
dat. 

Deci, o interfaţă bună va prezenta informaţia într-o manieră ierarhică. De 
exemplu, informaţia de control (comenzile disponibile ale aplicaţiei) se înglobează, 
de obicei, în meniuri, în funcţie de contextul de utilizare, o parte din opţiunile unui 
meniu, indisponibile la un moment dat, se pot ascunde sau inhiba, în plus, este 
posibilă introducerea unor instrumente de lucru suplimentare. Un exemplu este 
linia de intsrumente (toolbar-ui), care reuneşte comenzile de meniu mai frecvent 
folosite sub formă de butoane, tocmai în ideea ca accesarea acestor comenzi să se 
facă cât mai simplu. 


4.1.2. Ciclul de dezvoltare a unei interfeţe grafice utilizator 


Dezvoltarea unei GUI se bazează pe un ciclu iterativ, care cuprinde 4 faze: 
- determinarea cerinţelor; 
- construirea prototipului; 
- evaluarea prototipului, prin implicarea utilizatorului; 
- finalizarea. 

Din punct de vedere conceptual aceste faze sunt identice cu etapele de 
dezvoltare ale unei aplicaţii, cu menţiunea că fiecare fază are caracteristici şi 
elemente suplimentare specifice. 

Determinarea cerinţelor este etapa în cadrul căreia se decide forma generală 
a produsului final. Cu ajutorul utilizatorilor (prin interviuri sau întâlniri de lucru de tip 


JRP) se definesc obiectivele şi caracteristicile produsului, înţelegerea specificului 
aplicaţiei - practic, a problemelor cărora li se adresează aplicaţia: care este 
succesiunea operaţiunilor în varianta de rezolvare actuală şi cum se poate 
îmbunătăţi. Echipa de proiectare trebuie să urmărească şi alte elemente, precum 
categoria în care se încadrează utilizatorii, nivelul lor de cunoştinţe, tipul şi 
performanţele echipamentelor pe care va rula aplicaţia. 

Înainte de a trece la etapa următoare, sau în debutul acesteia, trebuie 
conturată interfaţa. Un instrument de modelare adecvat îl reprezintă diagramele 
de flux ale interfeţei. Acestea ilustrează relaţiile dintre componentele interfeţei 
(ecrane, rapoarte etc.) indicând practic modul în care lucrează efectiv aplicaţia. 
Prototipurile sunt şi ele foarte utile, fiind suficient de detaliate, dar există riscul de 
a pierde din vedere elementele esenţiale din cauza detaliilor. 
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Figura: de mai sus ilustrează o interfață pentru o aplicație destinată urmăririi 
comenzilor primite de la clienți. Fiecare casetă reprezintă un obiect al interfeței 
(form, raport, ecran), iar săgețile indică legăturile dintre eie şi fluxurile definite. 
Este foarte simplu de desprins o imagine globală asupra interfeței aplicației. 
Diagrama de flux poate fi apoi discutată cu utilizatorii şi se pot trage concluzii 
asupra consistenţei interfeței şi a logicii fluxurilor definite, în exemplul prezentat s- 
ar putea obiecta absenţa unei legături între ecranul de editare a clienţilor şi lista 
comenzilor clienţilor (afişarea comenzilor unui client selectat este o opţiune 
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plauzibilă într-o astfel de aplicaţie). Neconcordanţele de acest gen se pot depista 
foarte simplu prin crearea diagramelor de flux şi discutarea lor cu beneficiarii. 

Construirea prototipului porneşte de la cerinţele identificate în faza 
anterioară şi are în vedere transpunerea acestora într-un model concret. Se 
utilizează un instrument de prototipizare sau un limbaj de nivel înalt pentru a 
construi ecranele, dialogurile şi rapoartele ce vor constitui interfaţa aplicaţiei. Cel 
mai bun sfat pentru această etapă este să nu se acorde prea mare importanţă 
dezvoltării codului pentru implementarea comportamentului interfeţei, întrucât 
există şanse mari să apară modificări ale prototipului (cel puţin în primele variante) 
în faza de evaluare. 

Cei mai frecvent se utilizează bibliotecile de clase: fiecare element al GUI este 
definit ca o clasă, din care se va crea o instanţă în aplicaţia proiectată. 

Observaţie: dezvoltarea de prototipuri nu înlocuieşte diagramele de flux, cele 
două instrumente ar trebui utilizate în mod complementar. 

Experienţa recomandă construirea a trei tipuri succesive de prototipuri: un 
prototip făcut "de mână", care include doar funcţionalităţile de bază 
(fundamentale), apoi un prototip electronic, în care se transpun de asemenea doar 
funcţionalităţile de bază şi la urrnă un prototip electronic complet al interfeţei. 
Această metodă graduală de construire a prototipurilor s-a dovedit eficientă sub 
aspectul timpului consumat pentru această activitate, în plus, creşterea treptată a 
complexităţii pe măsura apropierii de soluţia finală îl ajută pe utilizator să înţeleagă 
cum va lucra de fapt aplicaţia proiectată. 

Evaluarea prototipului verifică dacă ceea ce propune echipa de proiectare 
(prototipul construit) corespunde cu ceea ce aşteaptă utilizatorii. Evaluarea 
răspunde de regulă ia 3 întrebări: ce este bun la prototip, ce nu este bun şi ce 
lipseşte prototipului. După evaluare se constată adesea că e nevoie să se renunţe la 
unele elemente, că trebuie adăugate componente noi, iar altele existente trebuie 
modificate. 

În această fază trebuie implicaţi activ utilizatorii produsului final sau - dacă e 
vorba de o aplicaţie destinată unei mase largi de utilizatori, evaluarea trebuie să o 
facă persoane care au caracteristicile celor cărora le este destinat produsul (în nici 
un caz evaluarea nu o vor face proiectanţii, pentru că intervine diferenţa de cultură 
şi experienţă şi, în plus, există riscul pierderii obiectivităţii în apreciere). 

Nemulţumirile şi obiecțiile celor care evaluează prototipul generează un ciclu 
iterativ care cuprinde fazele 2 şi 3. Acest ciclu de rafinare se repetă până când nu 
mai apar obiecţii sau cerinţe noi (sau cerinţele noi formulate sunt nesemnificative, 
de importanţă redusă). 


De-a lungul acestui proces iterativ, pe măsură ce prototipul sau componente 
ale acestuia primesc acceptul utilizatorilor, se trece la înlocuirea lor cu aplicaţia 
propriu-zisă. Trebuie evitate întârzierile ce pot apare de-a lungul ciclului de 
dezvoltare datorită scrierii programelor, înlocuirea prototipului cu aplicaţia trebuie 
să se facă în momentul în care nu mai pot apare schimbări semnificative în cadrul 
proiectului. 

Pe scurt, următoarele aspecte trebuie respectate pentru o prototipizare 
eficientă: 


cerinţele utilizatorului trebuie să fie punctul de plecare în elaborarea 
prototipului; 

înţelegerea problemei căreia i se adresează aplicaţia (prin discuţii cu 
utilizatorii cheie, documentare la faţa locului sau folosind documentaţia 
Internă existentă) - cu cât se va înţelege mai bine problema, cu atât 
interfaţa aplicaţiei va fi mai bună; 

- în faza de evaluare trebuie să se identifice: ce este bun la prototip, ce este 
rău la prototip, ce îi lipseşte; 

- se va opri prototipizarea atunci când evaluarea generează doar obiecţii 
minore; 

- folosirea, pe cât posibil, de obiecte din lumea reală - se vor exploata în 
acest fel cunoştinţele anterioare ale utilizatorului (asta presupune 
identificarea obiectelor reale care se potrivesc şi cunoaşterea modului în 
care oamenii interacționează cu ele); 

- planificarea timpului şi respectarea termenelor stabilite; 

- seva cere utilizatorilor finali să testeze şi să evalueze prototipul 
(implicarea acestora în faza de prototipizare are beneficii evidente); 

- nu se va investi prea mult timp în componente la care utilizatorii ar 
putea renunţa şi în scrierea de cod, întrucât acesta sigur va suferi 
modificări după evaluare; 

- pentru fiecare obiect din interfaţă se vor include în documentaţie: scopul şi 
modul său de utilizare, legăturile sale cu celelalte obiecte din interfaţă şi - 
dacă e cazul - scopul şi modul de utilizare a! componentelor sale. 

Documentarea fiecărui obiect se face doar după definitivarea sa în cadrul etapei de 
evaluare. 


4.2. Construirea interfeţelor grafice în VisualBasic 


În general, componentele grafice se pot încadra în una din următoarele mari 
categorii: 

e container - poate conţine alte obiecte sau containere. Se comportă ca obiect 
părinte pentru alte obiecte (formularul însuşi este un obiect de tip container 
pentru celelalte obiecte de pe el). Toate obiectele din container moştenesc 
valorile setate pentru unele din proprietăţile containerului (ex: Enabled, Visible 
etc...); În Visual Basic, pentru a construi un container dispunem de controlul 
Frame. 

e componente atomice - sunt utilizate pentru interacţiunea directă cu utilizatorul 
(butoane, căsuțe de text, liste de opţiuni, butoane de opţiune şi casete de 
validare) . 

Componentele grafice sunt în fapt clase definite de producătorii limbajului, clase 
pe care le utilizăm în crearea propriilor interfeţe grafice. 

Atunci când construim un formular, nu facem altceva decât să construim o nouă 
clasă, apelând la tehnica numită compunere (descrisă la capitolul 2). Cu alte 
cuvinte, atributele clasei noastre vor stoca obiecte aparţinând altor clase definite de 
producătorii limbajului (Form, TextBox, ListBox, etc.). Construirea clasei proprii se 
poate realiza şi prin cod, dar în majoritatea situaţiilor vom apela la facilităţile 
mediului vizual VB, suficient de intuitiv pentru a construi uşor şi rapid un formular de 
preluare date sau un raport. La momentul lansării în execuţie, se instanţiază clasa 
respectivă şi se obţine obiectul complex reprezentat vizual pe ecran. 

În acest material nu ne propunem să detaliem proprietăţile şi metodele de care 
dispune fiecare componentă grafică în parte, aceste aspecte fiind disponibile atât în 
lucrarea Finaru, L., Brava, |. “Visual Basic. Primii paşi şi următorii...” , Polirom ,2001, 
cap 4, 9, 14, cât şi în documentaţia standard VB. În schimb, vom detalia modelul de 
programare bazat pe evenimente precum şi modalitatea de a constui formulare VB 
“legate” la o bază de date relatională. 


4.2.1. Programarea bazată pe evenimente 


In programarea procedurală tradiţională, procesul de calcul este in intregime 
ghidat de instructiunile programului. Imediat ce s-a incheiat executarea unei 
instructiuni, se trece la instructiunea urmatoare, respectand fluxul programului 
respectiv. Aceasta se refera şi la interactiunea dintre program si utilizator. Chiar 
dacă programul este interactiv, initiaţiva privind datele ce trebuie introduse si in ce 
moment se introduc acestea aparţine programului. Operatorului uman nu îi ramane 
decat sa se conformeze solicitărilor acestuia şi să introducă date atunci cand ele 
sunt cerute de program. Este evident ca un asemenea rol nu este deloc convenabil 


pentru utilizator, care de cele mai multe ori doreşte să deţină controlul şi să fie el 
cel care ia iniţiativa acţiunilor. 

Apariţia interfeţelor grafice a permis introducerea unei noi concepţii in 
interactiunea dintre operator si aplicaţie, astfel că iniţiativa să îi revina operatorului 
uman, iar programul să execute comenzile acestuia. S-a trecut astfel de la 
programarea procedurala traditionala la programarea orientata pe evenimente 
(engleza: Event-Oriented Programming), cunoscuta şi sub numele de programare 
ghidata de evenimente (engleza: Event Driven Programming). 

Se numeşte eveniment orice modificare care are loc fie in starea dispozitivelor de 
intrare, fie in cea a obiectelor grafice de pe ecran: apasarea sau eliberarea unei 
taste, deplasarea mouse-ului, apasarea sau eliberarea unui buton al mouse-ului, 
deschiderea sau inchiderea unei ferestre, efectuarea unui clic de mouse pe un 
obiect de control (buton, caseta de validare, bara de defilare etc. ), intrarea 
cursorului mouse-ului în campul activ al unui obiect grafic sau părăsirea acestuia 
etc. Trebuie menţionat că pot exista şi alte tipuri de evenimente, fără legătură cu 
interfaţa grafică (vezi noţiunea de declanşator (trigger) pentru baze de date), dar 
aici ne intereseaza numai cele legate de interfaţa grafică a aplicaţiei. 

In programarea orientata pe evenimente, iniţiativa aparţine operatorului uman: 
acesta acţioneaza asupra dispozitivelor de intrare (tastatura, mouse si altele), 
generand astfel evenimente la care trebuie sa raspundă programul. 

Interactiunea dintre operator si aplicatie intr-un sistem bazat pe evenimente 
decurge astffel: 

e operatorul provoaca generarea unui eveniment, acţionand asupra 
tastaturii, mouse-ului sau a altui dispozitiv de intrare. In cazul tastaturii, 
evenimentul este generat prin apasarea sau eliberarea oricarei taste. In 
cazul mouse-ului generarea se face fie direct de catre acesta, ca urmare a 
deplasarii mouse-ului sau apasarii /eliberarii unui buton, fie de catre un 
obiect grafic de pe ecran, ca urmare a interacțiunii dintre acesta şi cursorul 
de mouse. 

e Evenimentul, astfel generat, poate declanşa execuţia unui modul de 
program, care defineşte o acţiune specifică în funcţie de tipul de 
eveniment şi obiectul grafic pentru care a fost declanşat. 

Problema care se pune în acest caz constă în identificarea modului de construire 
a unui program astfel încât el să reacționeze la evenimente. Arhitectura sistemului 
de operare Windows este destul de complicată şi nu ne vom ocupa aici de 
explicarea modului cum se nasc evenimentele; e suficient să ştim care sunt acestea 
şi că mediile de dezvoltare oferă mecanisme pentru captarea şi interpretarea 


acestor evenimente. În varianta Visual Basic şi a produselor similare, o aplicaţie 
constă dintr-un ansamblu de subrutine ce implementeaza logica aplicatiei 

Şi subrutine (proceduri sau subprograme) numite proceduri-eveniment şi care 
tratează un eveniment individual. O astfel de procedură este ataşată unui control şi 
se execută numai atunci când controlul respectiv interceptează evenimentul pentru 
care a fost scrisă. Altfel spus, un program va răspunde unui eveniment, care se 
produce la execuție, numai dacă a fost scrisă o procedură pentru evenimentul 
respectiv în combinaţie cu componenta grafică respectivă; in caz contrar, 
evenimentul va fi ignorat. 

Fiecare control plasat pe un form (ca şi form-ul însuşi) suportă mai multe tipuri de 
evenimente. De exemplu, o casetă de text poate răspunde la unul din următoarele 
evenimente: clic, dublu clic, introducerea unui text. Dacă pentru evenimentul clic 
este scrisă o procedură, atunci când aplicaţia se va lansa în execuţie iar utilizatorul 
va efectua clic pe caseta de text (se produce în acest fel evenimentul) - se va /ansa 
automat în execuţie procedura definită. Procedrile eveniment nu sunt cu nimic 
diferite de procedurile clasice. Singura chestiune ce trebuie reţinută este că 
denumirea acestora se alcătuiteşte astfel: 

Sub NumeObiectGrafic NumeEveniment (). 

Standardul de notatie trebuie obligatoriu respectat, altfel riscând să construim o 
procedură care va fi ignorată la apariţia evenimentului respectiv pentru simplul fapt 
că mediul run-time VisualBasic nu poate efectua asocierile necesare. 

Exemplu:  cmdup Click() reprezintă procedura eveniment clic ataşată 
controlului cmdup. Pentru dublu clic se va defini procedura cmdup DbIClLick(). 
Programatorul nu trebuie să-şi pună problema respectării acestei convenţii; 
denumirea procedurii-eveniment are loc automat, la prima accesare a acesteia. 

Observaţie: Parantezele şi liniuţa de subliniere (engl. underscore) sunt 
obligatorii în denumirea unei proceduri ce răspunde unui eveniment. Unele 
proceduri solicită prezenţa unei valori între paranteze, altele nu. În ambele cazuri 
parantezele trebuie să fie prezente. Aceste convenţii de scriere a numelor trebuie 
respectate obligatoriu, întrucât ele elimină orice ambiguitate în definirea 
procedurilor. 

Pentru exemplificare, presupunem că dorim să construim un formular prin 
intermediul căruia utilizatorul să introducă valori ce vor fi apoi sortate cu ajutorul 
unuia din algoritmii de sortare prezentaţi în capitolul 3. Aspectul formularului va fi 
cel din figura 4-1. Utilizatorul va avea la dispoziţie o căsuţă de text, denumită 
TxtValoare, prin intermediul căreia va actualiza (adăuga,modifica,şterge) 
elementele listei de valori (de tip ListBox) cu numele LstValori. La orice moment 
utilizatorul va avea posibilitatea sortării elementelor listei respective prin 


intermediul butonului corespunzător (cu numele cmdSortează) şi al butoanelor de 
opţiune disponibile (denumirea acestor butoane radio este deasemenea construită 
conform notaţiei ungureşti: optAscendent, optDescendent, optNesortat) 
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Figura 4-1 Un exemplu de formular VB 


Utilizatorul va putea actualiza lista de valori prin una din următoarele tehnici 
disponibile: 

- introduce un text în căsuţa TxtValoare şi îl adaugă în lista LstValori prin 
intermediul butonului “Adaugă” (cu numele cmdAdaugă) 

- la selectarea unui element deja existent în listă, valoarea respectivă trebuie 
să fie disponibilă în căsuţa de text pentru a fi eventual modificată şi 
actualizată lista prin intermediul butonului “Modifică” (cu numele 
cmdModi fica) 

- ştergerea elementului curent selectat în listă prin apăsarea butonului 
“Sterge” 


O dată construită macheta formularului conform figurii 4-1, va trebui să 
implementăm procedurile specifice fiecărui eveniment prin care trebuie asigurată 
funcţionalitatea descrisă mai sus. 

Primul pas în realizarea acestui deziderat este de a identifica evenimentele 
generate de diversele componente grafice ce trebuiesc interceptate şi la apariţia 
cărora trebuie să se asigure un comportament addecvat. Important de remarcat 
este faptul că, deşi fiecare componentă grafică poate genera mai multe tipuri de 
evenimente (click, change, gotfocus,lostfocus,valid, etc.), trebuie identificate 
doar acelea care au relevanţă din perspectiva funcţionalităţii ce trebuie 
implementată. Astfel: 

- pentru butoanele de comandă vom identifica evenimentul click drept 
eveniment relevant, acesta declanşându-se apăsarea butonului atât prin 
intermediul mouse-ului cât şi prin tastatură (tasta Enter atunci când butonul 
deţine controul curent al tastaturii). Pentru fiecare din butoanele de 
comandă vom impelmenta o secvenţă de cod specifică (ce se va executa 
drept răspuns la acelaşi eveniment click) în funcţie de operaţia ce trebuie 
realizată (adăugare,modificare, ştergere sau sortare); 

- pentru căsuţa de text (txtValoare) nu există deocamdată un eveniment ce 
trebuie interceptat, ea fiind doar instrumentul prin care utilizatorul 
introduce noile valori. 

- Pentru lista de valori (IstValori) va trebui să identificăm evenimentul ce 
se declanşează la selectarea unui element al listei, pentru a prelua valoarea 
selectată şi a o introduce în căsuţa de text astfel încât utilizatorul să o 
poată modifica. Pentru componenta grafică de tip ListBox, în VisualBasic, 
acest eveniment este denumit tot click şi se declanşează fie la selectarea 
unui element cu ajutorul mouse-ului, fie la selectarea cu ajutorul tastaturii 
(tastele Up şi Downd). 

Aşa cum spuneam ceva mai devreme, pentru a crea o procedură care să se 
execute ca răspuns la apariţia unui eveniment poentru un anumit obiect grafic, 
trebuie să respectăm un standard de notație : Sub 
NumeObiectGrafic NumeEveniment () 

Numele procedurii poate fi bineînţeles scris ca atare în modulul aferent 
formularului dar poate fi şi generat automat prin executarea unui dubluclick pe 
componenta grafică respectivă şi apoi selectat evenimentul din lista specifică (vezi 
figura 4-1). Listingul 4-1 prezintă procedurile specifice pentru formularul nostru 
(lipseşte procedura pentru butonul Sorteaza). Pentru proprietăţile şi metodele 


obiectelor grafice consultaţi materialul: Finaru, L., Brava, |. “Visual Basic. Primii paşi 
şi următorii...” , Polirom ,2001, cap 4, 9, 14. 


Listing 4-1. Procedurile pentru implementarea comportamentului formularului 


Private Sub cmdAdauga_Click() 

If TxtValoare.Text <> "" Then 
LstValori.Addltem (TxtValoare.Text) 
TxtValoare.Text = "" 
TxtValoare.SetFocus 

End If 

End Sub 


Private Sub CmdModifica_Click() 

If TxtValoare.Text <> "" Then 
indexCurent = LstValori.ListIndex 
LstValori.Removeltem (indexCurent) 
Call LstValori.Addltem(TxtValoare.Text, indexCurent) 


End If 
End Sub 
Private Sub CmdSterge_ Click() 
If LstValori.SelCount <> 0 Then 
LstValori.Removeltem (LstValori.ListIndex) 
End If 


End Sub 


Private Sub LstValori Click() 
TxtValoare.Text = LstValori.List(LstValori.ListIndex) 


End Sub 


Pentru a exemplifica şi interceptarea unui alt tip de eveniment, să presupunem 
că dorim să obligăm utilizatorul să introducă doar secvenţe numerice în căsuţa de 
text. În caz contrar, formularul trebuie să nu permită părăsirea căsuţei de text până 
când situaţia nu este remediată. Acest aspect face parte dintr-o problematică mai 
largă, cunoscută sub numele de validarea datelor. Spre deosebire de alte limbaje, în 
VisualBasic validarea datelor poate fi realizată foarte simplu prin scrierea unei 
proceduri care să răspundă evenimentului Validate. lată procedura pentru 


validarea datelor numerice în căsuţa TxtValoare a formularului nostru: 


Private Sub TxtValoare_Validate(Cancel As Boolean) 
If TxtValoare.Text <> "" And Not IsNumeric(TxtValoare.Text) Then 
Cancel = False 
Else 
Cancel = true 


End If 


End Sub 


Se observă că procedura primeşte un parametru (de tip Boolean) cu numele 
Cancel. Având în vedere că acest parametru este trimis prin referinţă (nu este 
specificat explicit ByVal, deci se transmite în mod implicit ByRef), secvenţa de cod 
ce constituie implementarea procedurii trebuie să verifice validitatea datelor 
introduse de utilizator şi să atribuie parametrului Cancel valoarea false în cazul în 
care restricţiile sunt încălcate. Valoarea false va determina mediul VB să nu 
permită părăsirea căsuţei de text, iar valoarea true va determina comportament 
normal. 


4.3. Acces la baze de date din VB 


Pe parcursul timpului, Microsoft a dezvoltat mai multe tehnologii pentru a conecta 
o aplicaţie scrisă într-un limbaj de programare, precum VisualBasic, la o sursă de 
date externă. Iniţial, cea mai populară astfel de tehnologie a fost: Data Access 
Objects (DAO) - dedicată în exclusivitate accesului la baze de date Access (Jet). La 
un moment dat, Microsoft a dezvoltat un o interfaţă de nivel intermediar - Remote 
Data Objects (RDO) - pentru manipularea datelor altor SGBD-uri relaţionale, care nu 
se aflau pe aceeaşi staţie de lucru. Cu alte cuvinte, RDO asigură în plus nivelul de 
transport al datelor prin reţea, între server şi aplicaţia client. Această nouă interfaţă 
nu este destinată utilizării directe de către dezvoltatorii de aplicaţii ci se constituie 
ca un nivel de mijloc între DAO şi bazele de date relaţionale. 

În ultima vreme, un nou standard a fost impus ca fiind cea mai eficientă 
modalitate de acces la orice tip de sursă de date externă (relaţională şi non- 
relaţională): Universal Data Access (UDA). Prin această nouă abordare, dezvoltatorul 
de aplicaţii are la dispoziţie un set predefinit de funcţii specifice pe care le utilizează 
indiferent de tipul sursei de date pe care doreşte să o acceseze (FoxPro, Oracle, 
Access, Excel, etc...). Mai mult, UDA este un ansamblu de instrumente software 
independent de limbaj, astfel că aceleaşi funcţii specifice vor fi utilizate atât de 
programatorii VB cât şi C#, .NET, etc. 

În prezent standardul UDA este implementat de următoarele tehnologii (acestea 
împreună formează UDA): 

e ActiveX Data Objects (ADO) - o interfaţă software de nivel înalt, utilizată de 
obicei în mod direct de către majoritatea dezvoltatorilor, ce furnizează 
toate funcţiile necesare manipulării datelor din orice sursă de date la nivelul 
unor aplicaţii scrise într-un limbaj pre - .NET 

e ADO.NET -aceeaşi interfaţă rescrisă pentru noua platformă .NET ; 

e ODBC - Open Database Connectivity - un standard middleware pentru 
acces la baze de date relaţionale; 


e OLE-DB- Object Linking and Embedding DB - ultima generaţie de standard 
middleware pentru acces la orice sursă de date, nu neapărat relaţională 
(XML, Text, Video, etc) 


| VB 6.0 APPLICATION | 


| Other | 
nor-relational | 
|_Data Source | 


| SQL Data 
| Source 


Figura 4-2 Tehnologii Microsoft pentru acces la surse de date externe (sursa - 
http://msdn.microsoft.com) 

Analizând figura 4-2, observăm că cele două tehnologii , DAO şi ADO (ultima 
generaţie), sunt produse software de nivel înalt destinate utilizării directe de către 
dezvoltatorii de aplicaţii ce implică acces la date. Între acestea şi sursa de date mai 
există însă un nivel de interfeţe (middleware) ce pot să se prezinte sub forma : 
ODBC (tradiţional) sau OLE DB (ultima generaţie) 


4.3.1. Standarde de comunicare cu surse de date 


ODBC 

ODBC constituie o interfaţă software al cărei scop este acela de a furniza o 
modalitate standardizată de acces la orice sursă de date ce se conformează 
modelului relaţional, indiferent de furnizorul SGBD-ului (IBM-DB2, Oracle, SQL- 
Server, FoxPro, Access, etc.). ODBC este un standard neutru (independent de un 
anumit producător). 

Pentru a furniza o modalitate standardizată de acces la date în diverse formate, 
ODBC introduce un nivel-aplicaţie intermediar, numit driver al bazei de date, între 
aplicaţia client şi motorul bazei de date. Un driver este în esenţă un set de programe 


dezvoltat de un furnizor de SGBD, set de programe care se conformează unui 
standard (în cazul de faţă ODBC) şi al cărui scop este: 


de a asigura translaţia comenzilor de interogare/actualizare disponibile la 
nivelul aplicaţiei client în comenzi similare pentru SGBD-ul respectiv 
(comenzi pe care acesta din urmă le “înţelege”); 

de a returna rezultatul interogărilor (datele extrase) într-un format 
standard, prin care să se ofere posibilitatea aplicaţiei client de a le prelucra. 


Caracteristicile generale ale ODBC sunt: 


eficienţă sporită; 

dificultate în scrierea codului 

cerinţe de resurse (memorie, CPU) rezonabile 
compatibilitate cu tehnologiile de daze de date existente 
portabilitate la nivelul sistemelor de operare 


Esenţial de remarcat este faptul că ODBC se adresează aproape în exclusivitate 
accesului la date stocate în baze de date relaţionale, orice alt format de stocare fiind 
complicat de gestionat prin intermediul ODBC. 

La nivel arhitectural, ODBC are la bază patru componente: 


Application programming interface (API) - set de funcţii (programe) la care 
au acces aplicaţiile client şi care sunt utilizate de pentru a invoca funcţiile 
interne ODBC în următoarele scopuri: 
o Stabilirea unei conexiuni la baza de date 
o Preluarea unui set de date din sursa de date 
o Trimiterea spre executie a unor comenzi de actualizare a datelor 
o Închiderea conexiunii 
Gestionar de drivere (Driver manager) - furnizează informaţii către aplicaţia 
client cu privire la lista de surse de date disponibile şi încarcă driverele în 
mod dinamic pe măsură ce sunt necesare unei aplicaţii sau alteia 
Driver - este componenta furnizată în mod specific de proprietarul SGBD- 
ului şi care îndeplineşte următoarele funcţii: 
o procesează efectiv apelurile aplicaţiei client către funcţiile ODBC; 
o îi revine în exclusivitate sarcina de a gestiona schimburile de date 
între aplicaţia-client şi baza de date ; 
o dacă este necesar, asigură translaţia comenzilor SQL standard în SQL 
nativ (specific) pentru sistemul respectiv de gestiune a BD 
Sursa de date (data source) - cuprinde datele intrinseci şi motorul de 
gestiune a bazei de date asociat 
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Figura 4-3 Arhitectura ODBC 


Data Data 
Source Source 


Aspectul fundamental ce trebuie reținut în legătură cu ODBC se referă la faptul că 
dezvoltatorii de aplicaţii vor utiliza acelaşi set de funcții furnizate de ODBC-API, 
indiferent de SGBD-ul la care se conectează. Ca urmare, dezvoltatorii nu vor fi 
nevoiţi să înveţe comenzi SQL specifice fiecărui SGBD (deşi SQL este în sine un 
standard, majoritatea producătorilor de SGBD-uri implementează şi extensii proprii), 
funcțiunea de translație SQL standard >SQL proprietar fiind asigurată de driver. 

În general, pentru a lucra cu baze de date prin ODBC, o aplicație va parcurge 
următorii paşi: 


1. 


Alocarea unei conexiuni - se alocă spațiu de memorie pentru datele specifice 
conexiunii 


. Conectare - se specifică informaţiile de identificare a sursei de date şi 


autentificare (nume utilizator, parola) 


. Alocarea frazei SQL - fraza SQL se asociază unei conexiuni. Pot fi asociate mai 


LL 


multe fraze SQL cu o coenxiune dar numai una este cea “activă” la un 


moment dat 


. Execuţia frazei SQL - este faza de procesare a frazei SQL : 


a. Fraza este trimisă driver-ului 

b. Driver-ul o converteşte în SQL nativ SGBD-ului (eventual) şi o trimite 
motorului BD pentru execuţie 

c. Motorul BD execută fraza SQL şi returnează rezultatul 

d. Driver-ul preia datele-rezultat, le converteşte (eventual) pentru a fi 
inteligibile aplicaţiei-client, şi le trimite aplicaţiei-client 


. Prelucrarea setului de rezultate - aplicaţie client preia de la driver rezultatele 


şi le utilizează în mod specific; 


6. 


Eliberarea conexiunii (dealocarea frazei SQL)- aplicaţia-client distruge 


elementele de asociere frază-conexiune. În acest moment se poate aloca o 
nouă frază SQL respectivei conexiuni; 

7. Deconectarea - presupune ştergerea informaţiilor de conectare de la nivelul 
conexiunii; 

8. Dealocarea conexiunii - eliberarea spaţiului de memorie utilizat de conexiune; 


4.3.2. ActiveX Data Objects 


După cum precizam şi ceva mai devreme, ADO reprezintă o interfaţă de nivel 
înalt destinată utilizării directe de către dezvoltatorii de aplicaţii ce implică acces la 
date stocate în surse externe. 

ADO furnizează un model logic obiectual suficient de flexibil pentru a interoga 
şi actualiza datele rezidente în surse externe. Accesul la date se realizează prin 
intermediul interfeţei software OLE DB dar acest nivel de mijloc este total 
transparent pentru programator. Ca urmare, programatorii nu trebuie decât să 
înţeleagă filozofia şi funcţionalitatea interfeţei ADO pentru a dezvolta aplicaţii 
robuste ce necesită acces la baze de date. 

lată o parte din vasta funcţionalitate a acestei tehnologii: 


Interogarea unei baze de date, utilizând SQL, şi afişarea rezultatului; 
Crearea şi reutilizarea comenzilor SQL parametrizate; 

Crearea dinamică a unei structuri tabelare flexibile, denumită Recodset, 
pentru a manipula datele extrase din BD; 

Furnizarea unui mecanism pentru a grupa actualizările sensibile în 
tranzacţii distincte; 

Conectarea atributelor unei tabele la componente grafice specializate de 
tip “data-aware” ; 

Filtrarea şi sortarea dinamică (pe baza unor parametri furnizaţi la runtime) 
a copiilor locale ale datelor extrase din BD 

Actualizarea înregistrărilor tabelelor din baza de date; 

Crearea obiectelor în baza de date; 

Lansarea în execuţie a procedurilor stocate în baza de date; 

Extragerea informaţiilor dintr-un fişier stocat pe Internet; 

Manipularea mesajelor şi structurilor de stocare într-un sistem e-mail; 
Slavarea datelor extrase dintr-o bază de date într-un alt format: spre 
exemplu fişier XML (eXtendedMarkupLanguage); 


Pentru a oferi o asemenea flexibilitate, ADO furnizează o largă varietate de 
opţiuni de setare şi funcţii specifice. De aceea este important a se urmări o abordare 
metodică pentru a identifica modalitatea de utilizare a ADO în aplicaţiile proprii. 

Configurarea mediului VisualBasic pentru ADO 

Interfața ADO trebuie importată din bibliotecile externe ActiveX, pentru a fi 
disponibilă în VB 6.0. Astfel: opţiunea Project[lReferences va deschide fereastra 
din figura 4-4, unde regăsim o listă cu toate componentele ActiveX disponibile. Aici 
trebuie selectată componenta Microsoft ActiveX Data Objects şi Microsoft ActiveX 
Data Objects Recodset. 
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åvailable References: 


Microsoft Activex Data Objects 2.1 Library 

Microsoft Activex Data Objects 2.6 Librar: 5 
7 
v| Microsoft Activex Data Objects Recordset 2.7 Library 

Microsoft Activex Plugin 

Microsoft ådd-In Designer 

Microsoft ADO Ext. 2.7 for DDL and Security 

Microsoft Agent Control 2.0 

Microsoft Agent Server 2.0 

Microsoft Agent Server Extensions 2.0 

Microsoft AutoDiscovery Type Library 

Microsoft Browser Helpers 

Microsoft CDO For Exchange 2000 Library 
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Location: C:\Program Files\Common Filesisystemiadoimsado15, dl 


Language: Standard 


Figura 4-4 Integrarea componentelor ActiveX Data Objects într-un poriect VB 


Modelul Obiectual ADO 

Tehnic vorbind, interfaţa ADO se constituie dintr-un set de clase predefinite 
fiecare specializată pentru o anumită operaţie: realizarea conexiunii cu sursa de 
date, execuţia unei comenzi (SQL sau non-SQL) pe serverul BD, manipularea datelor 
din sursa de date, tratarea erorilor. Figura 4-5 prezintă ansamblul acestor clase, şi 
dependenţele dintre ele iar tabelul 4-1 descrie succint funcţionalitatea (scopul) 
fiecăreia. Unele clase vor fi reprezentate prin obiecte distincte, altele sub formă de 
colecţie - asta înseamnă că programatorul va gestiona elementele colecţiei 
respective, elemente care vor fi în fapt obiecte dintr-o anumită clasă. 

Ca urmare, la nivelul aplicaţiei-client, dezvoltatorul nu va trebui decât să 
manipuleze în mod corespunzător obiecte din aceste clase pentru a-şi asigura 
accesul la date şi prelucrarea acestora. 


Clasa / forma de 
gestionare în 
aplicaţie 


Connection - 
obiect 


Command - 
obiect 


Recordset - 
obiect 


Record - obiect 


Connection 


Figura 4-5 Modelul obiectual ADO 


Descriere 


Un obiect din această clasă reprezintă o sesiune distinctă 


(conexiune) către 
proprietăţilor(atributelor) 


sursa 


Şi 


de 


metodelor 


Prin 
acestei 


date. 
clase 


intermediul 


se 


specifică informaţiile de conectare (localizarea sursei de date, 


nume de utilizator, 
furnizate şi 


parolă, etc.). 
metode pentru a 
comite/anula actualizările efectuate în tranzacţia respectivă. 


Tot la acest nivel 
iniţia o tranzacţie şi 


sunt 


a 


Prin intermediul unui obiect din acestă clasă se definesc 
comenzi ce vor fi trimise sursei de date spre execuţie (spre 


exemplu o interogare SQL) 


Un obiect Recordset reprezintă (încapsulează) fie întregul 
set de înregistrări obţinut în urma execuţiei unei comenzi 
Select-SQL, fie rezultatul execuţiei unei alte comenzi (numărul 
de înregistrări afectate de o frază SQL de actualizare date sau 
rezultatul returnat de execuţia unei funcţii stocate la nivelul 


sursei de date) 


Toate obiectele Recordset conţin la rândul lor obiecte de 


tip Record şi 


de tip Field 


Un obiect Record nu este altceva decât o altă reprezentare 
(la nivelul aplicaţiei) a datelor unei singure înregistrări din 


sursa de date. 


Parameter - Reprezintă un argument (parametru) ce va fi asociat unui 
obiect obiect Command pentru a construi fraze SQL parametrizate sau 
a furniza valori actuale pentru parametrii formali definiţi la 

nivelul procedurilor stocate în sursa de date. 


Field - obiect Reprezintă o coloană în Recordset şi este, în majoritatea 
cazurilor , asociat unei coloane (atribut) al unei tabele 
relaţionale. 


Property - obiect Reprezintă un atribut distinct (definit suplimentar 
atributelor furnizate implicit de clasele ADO) prin care se 
gestionează o caracteristică distinctă, proprietară unei 
anumite surse de date. 

Error - obiect Conţine detaliile unei eventuale erori ce s-a declanşat la o 
anumită operaţie executată de sursa de date. Programatorul 
aplicaţiei-client va trebui să trateze în mod specific aceste 
erori pentru a obţine în final o aplicaţie stabilă. Informaţiile 
despre respectiva eroare vor fi preluate prin intermediul 
atributelor specifice ale acestui obiect: 

ObjError.number, 
ObjError.Source, 
ObjError.Description 


(vezi listing 4-3) 


Fields - colecţie O colecţie ce cuprinde toate obiectele Field asociate unui 
obiect Recordset sau Record. 
Properties - Conţine toate obiectele de tip Property asociate unui 
colecţie anumit obiect. 
Parameters - Conţine toţi parametrii (obiecte de tip Parameter) asociaţi 
colecţie unei comenzi (obiect Command). 
Errors - colecţie Colecţie ce conţine toate obiectele Error generate la 


execuţia unei comenzi (de multe ori execuţia unei anumite 
comenzi de câtre sursa de date poate genera nu o singură 
eroare ci mai multe). 


Crearea unei surse de date ODBC pentru acces la o BD VisualFoxPro 
Există mai mult modalităţi de a obţine o conexiune către o sursă de date externă: 
- specificarea tuturor informaţiilor de conectare necesare (localizarea sursei 
de date, informaţii de autentificare, ş.a.) prin intermediul proprietăţilor unui 
obiect Connection 
- construirea unei conexiuni ODBC (numită DSN - Data Source Name), toate 
informaţiile necesare fiind specificate la acest nivel 
Recomandabilă este ultima variantă şi o vom exemplifica în cele ce urmează. 
O modalitate de a intra în mediul de configurare ODBC este prin intermediul 
sistemului de operare: Control Pannel > Administrative Tools > ODBC 
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Figura 4-6 Localizarea instrumentului vizual de configurare ODBC 


Paşii ce trebuie parcurşi apoi sunt următorii (vezi şi figura 4-7): 

1. în fereastra User DSN (sau System DSN) se apasă butonul Add pentru a 
construi sursa de date 

2. se selectează driverul corespunzător furnizorului sursei de date externe 
(pentru detalii vezi arhitectura ODBC descrisă al începutul acestui capitol) şi 
se apasă butonul Finish; pentru că în exemplele noastre viitoare ne vom 
conecta la o bază de date VFP, în cazul de faţă selectăm driverul Microsoft 
Visual FoxPro Driver (dacă nu există poate fi descărcat de pe Internet, la 
adresa : 

http://msdn.microsoft.com/vfoxpro/downloads/updates/odbc/ 

default.aspx ) 


3. în fereastra obţinută introducem informaţiile de conectare: 
a. denumirea sursei de date (în exemplul nostru: ConexiuneVFP)- acesta 
va fi informaţia pe care o vom utiliza la construirea unei conexiuni ADO 
b. descrierea sursei este opţională 
localizarea bazei de date - se va căuta pe disc (cu butonul Browse) 
fişierul cu extensia .dbc ce constituie dicţionarul bazei de date (în cazul 
nostru salariibd.dbc) 
4.  seapasă butonul OK, şi se părăseşte sistemul de configurare ODBC 
În acest moment dispunem de o sursă ODBC cu numele ConexiuneVEP prin prin 
intermediul căreia vom realiza conexiuni ADO către baza de date salariibd.dbc. 
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Figura 4-7 Construirea unei surse de date ODBC pentru conexiuni către o bază de date VFP 


Primul Test ADO 


În general, atunci când este necesar acces la date, o aplicaţie VB parcurge 
următorii paşi: 

1. instanţiază clasa Connection şi utilizează metodele obiectului obţinut 
pentru a furniza informaţiile de conectare şi a deschide conexiunea cu 
sursa de date 

2. efectuează operaţiuni de citire/actualizare date; manipularea datelor se 
poate realiza în două moduri: 

o se utilizează metoda execute() a obiectului Connection pentru a 
trimite către sursa de date o comandă de actualizare a datelor 
(Update, Delete, Insert) 

o se instanţiază clasa Recordset şi se invocă metoda open() pentru 
a trimite o cerere de interogare (Select SQL) către sursa de date, 
cerere al cărei rezultat va fi preluat de structura internă a 
obiectului Recordset; datele vor putea apoi fi manipulate prin 
intermediul metodelor specifice ale Recordset-ului; în funcţie de 
parametrii furnizaţi metodei open, datele vor fi actualizabile sau 
nu prin intermediul Recordset-ului (vom reveni cu amănunte ceva 
mai târziu) 


3. închide conexiunea cu sursa de date atunci când nu mai sunt necesare 
operaţii de acces la date 
Un prim exemplu va consta în extragerea şi afişarea datelor pentru angajaţii din 


compartimentul Financiar (fraza Select pentru interogarea bazei date va fi : Select * 
from personal where compart="fin') 

Notă. Structura bazei de date este cea definită la laboratorul Baze de date 1 

lată codul sursă VisualBasic: 


Listing 4-2 Afişarea înregistrărilor tabelei Personal prin intermediul ADO 


Sub PrimulTest() 

Dim adoConnection As ADODB.Connection 
Dim adoRsetPersonal As ADODB.Recordset 
Dim frazaSQL As String 


-- crearea unui obiect Connection -- 
Set adoConnection = New ADODB.Connection 


-- crearea unui obiect Recordset -- 
Set adoRsetPersonal = New ADODB.Recordset 


-- deschiderea conexiunii — 
adoConnection.CursorLocation = aduseClient 
adoConnection.Open ("ConexiuneVvFP") 


'—incarcarea Recodset-ului prin interogarea bazei -- 
frazaSQL = "select personal.* from personal where compart='fin' order by numepren" 
Call adoRsetPersonal.Open(frazaSQL, adoConnection) 


'-- parcurgerea Recodset-ului -- 


Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("'marca").Value &"" 
& adoRsetPersonal.Fields("numepren").Value 4" " 
& adoRsetPersonal.Fields("datasv").Value 6" " 
& adoRsetPersonal.Fields("salorar").Value ) 
adoRsetPersonal .MoveNext 
Loop 
1-- inchiderea conexiunii -- 
adoRsetPersonal.Close 
adoConnection.Close 


End Sub 


lată şi rezulatul execuţiei procedurii, obţinut în fereastra Immediate 


primultest 

25639 ALECSA CONSTANTIN 18/10/1995 440000 
26331 ASOFIEI P.MARINEL 08/03/1990 850000 
21171 BALAN IOAN 3041272000 60000 
27801 BUNDUC PAUL 13/08/1996 380000 


21164 CHIRIAC COSTEL 11/12/1998 21000099 
21176 CIOPEICA I.DORU 24/08/1992 670000 
27829 ENACHE ST. IONEL 25/05/1998 250000 
1008 GADSGCYGCUDY 2341041994 1000000000 


Dacă analizăm cu atenţie secvenţa de cod din listingul 4-2, se observă că 
respectă procedura generală de lucru prezentată la începutul aceste secţiuni. 

Astfel, modalitatea de abordare este următoarea: 

1. Se declară variabilele necesare a stoca referinţe spre obiectul Connection şi 


obiectul (sau obiectele) Recordset necesare: 


Dim adoConnection As ADODB.Connection 
Dim adoRsetPersonal As ADODB.Recordset 
Dim frazaSQL As String 


2. Se instanţiază clasele respective pentru a obţine obiectele necesare: 


1-- crearea unui obiect Connection -- 
Set adoConnection = New ADODB.Connection 


'-- crearea unui obiect Recordset -- 
Set adoRsetPersonal = New ADODB.Recordset 


Este important de remarcat faptul că trebuie specificat pachetul ADODB pentru a 

instanţia clase Connection şi Recorset de tip ADO şi nu DAO. Pachetul ADODB 

este disponibil numai dacă a fost configurat mediul VB conform indicaţiilor 

precizate la începutul acestui subcapitol (4.3.2) 

3. Se deschide conexiunea cu baza de date, furnizând metodei open() a 
obiectului Connection informaţiile necesare pentru conectare. În cazul de 
faţă, informaţia se referă la numele sursei ODBC construită în secţiunea 


anterioară (ConexiuneVFP). 


-- deschiderea conexiunii — 
adoConnection.CursorLocation = aduseClient 
adoConnection.Open ("ConexiuneVvFP") 


O altă informaţie importantă se referă la localizarea setului de rezultate a unei 

interogări SQL (pe serverul BD sau în spaţiul de memorie al clientului VB). În 

acest sens este disponibilă proprietatea CursorLocation ce poate lua o valoare 
definită prin intermediul unor constante definite la nivelul clasei Connection 

(vom reveni cu amănunte mai târziu) 

4. se trimite fraza SQL spre execuţie către sursa de date (în cazul nostru 
motorul BD al VFP) şi se încarcă (deschide) Recordsetul. În acest sens se 
utilizează motoda open() a obiectului Recordset obţinut anterior. Primul 
parametru al acestei metode va fi şirul de caractere ce constituie fraza SQL , 
iar al doilea parametru va fi obiectul Connection prin intermediul căruia 
dorim să declanşam opearţia de comunicare (deşi, în general lucrăm cu un 
singur obiect Connection, există posibilitatea ca o aplicaţie să deschidă şi 


să utilizeze mai multe conexiuni deodată) 


'—incarcarea Recodset-ului prin interogarea bazei -- 
frazaSQL = "select personal.* from personal where compart='fin' order by numepren" 
Call adoRsetPersonal.Open(frazaSQL, adoConnection) 


5. O dată executată metoda open(), Recordset-ul este încărcat cu datele 
primite de la sursa de date şi putem utiliza metodele şi proprietăţile acestuia 
pentru a manipula datele (vom reveni cu detalii în câteva momente). Pentru 
acest exemplu se parcurge setul de date prin invocarea metodei MoveNext() 
a obiectului Recordset în cadrul unei bucle While. Condiţia de ieşire din 
buclă se asigură prin testarea atributului (proprietăţii) EOF , de tip boolean, 
care va returna valoarea true o dată ce s-a apelat metoda MoveNext pentru 
ultima linie din Recordset. 

Prin interogarea colecţiei Fields - Fields (“numecamp”)- vom obţine un 
obiect Field ce constituie reprezentarea obiectuală ADO a câmpului 
“numecâmp” extras din sursa de date în urma interogării (vezi structura 
obiectuală ADO şi precizările ce vor urma acestei secţiuni). Proprietatea 
(atributul) value a acestui obiect va returna valoarea câmpului respectiv 


de pe linia curentă din Recodset. 


Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("'marca").Value &"" 
& adoRsetPersonal.Fields("numepren").Value 4" " 
& adoRsetPersonal.Fields("datasv").Value 4"! _ 
& adoRsetPersonal.Fields("salorar").Value ) 
adoRsetPersonatl. MoveNext 
Loop 


6. se închide recordset-ul şi conexiunea prin utilizarea metodei close) 


furnizată de ambele obiecte 


adoRsetPersonal.Close 
adoConnection.Close 


Clasa Connection 
În cele ce urmează vom detalia clasa Connection pentru a evidenția 
funcţionalitatea de ansamblu pe care o oferă aceasta. 
Clasa Connection defineşte următoarele metode: 
e open(ConnectionString, UserID, Password) - stabileşte conexiunea 
fizică între aplicaţie şi sursa de date externă. Primul parametru va fi, de 
cele mai multe ori, denumirea sursei de date ODBC configurată pentru o 
anumită sursă de date. Ultimii doi parametri sunt opţionali. Dacă sursa 
externă este un server de BD (Oracle, MS-SQLServer) informaţiile de 
autentificare a utilizatorului (nume şi parolă) pot fi specificate la contruirea 
sursei ODBC sau, la deschiderea conexiuniii, prin intermedul ultimilor doi 
parametri. 
e close() - închide conexiunea cu sursa de date. Deşi VB asigură închiderea 
conexiunilor la finalizarea unei aplicaţii, este bine ca programatorul să nu se 


bazeze pe acest comportament implicit şi să închidă explicit toate 
conexiunile deschise, înainte de închiderea aplicaţiei-client 

e execute(CommandText,  RecordsAffected, Options) - execută o 
comandă, specificată de parametrul CommandText, la nivelul sursei de date. 
Comanda este furnizată sub forma unui String (şir de caractere) şi specifică 
de obicei o frază SQL (DML sau DDL). Dacă fraza SQL este o interogare 
(Select SQL), metoda va returna un obiect Recordset cu rezultatul 
interogării, obiect care va trebui preluat de o variabilă corespunzătoare, 
astfel: 

DIM rezultat as ADODB.Recordset 
Set Rezultat=objConnection.execute (“select * from personal”); 

Important! Întotdeauna o comandă Select-SQL executată prin 
această metodă va genera un Recordset de tip “read-only” şi care 
poate fi parcurs o singură dată. 
De aceea aceatsă metodă este indicat a se utiliza pentru comenzi SQL de 
actualizare a datelor sau de definire a obiectelor in baza de date (Update, 
Insert, Delete, Create Table, etc.) pentru a obţine un set de date utilizându- 
se metoda open() a unui obiect Recordset, (vezi mai jos secţiunea dedicată 
clasei Recordset) 
Parametrul opţional  RecordsAffected (de tip Long) este transmis prin 
referinţă şi va fi utilizat de driver-ul asociat sursei de date pentru a specifica 


numărul de înregistrări afectate de comandă. Spre exemplu: 


DIM nrinregistrariupdate as Long 
ObjConnection.execute(“update personal set salorarco=salorarco+100000 where  compart=fin' 
nrinregistrariupdate) 
Debug.print (“au fost modificate:” & nrinregistrariupdate _ 
& ” înregistrari”) 


e BeginTrans() - specifică începutul unei sesiuni tranzacţionale - toate 
actualizările efectuate din momentul respectiv vor putea fi anulate ulterior 

e CommitTrans() - comite (permanentizează) actualizările efectuate în 
tranzacţia curentă 

e RollBackTrans() - anulează actualizările efectuate în tranzacţia curentă 


Vom reveni cu amănunte relativ la tranzacţii în secţiunile ce urmează. 
Majoritatea proprietăţilor definite de clasa Connection se referă la informaţiile 


de conectare. (nu le vom detalia aici). Există însă şi o proprietate ce trebuie 
tratată cu ceva mai multă atenţie: 


e CursorLocation - prin intermediul ei se specifică localizarea setului de 
date obţinut în urma unei interogări SQL. Proprietatea trebuie setată înainte 
de deschiderea conexiunii! Există două constante ce pot fi utilizate : 

0bj Connection.CursorLocation= aduUseClient - cursorul (setul de rezultate 
- vezi secţiunea rezervata clasei Recordset) va fi furnizat de bibliotecile de 
clase ale aplicaţiei client, oferind o multitudine de proprietăţi standard 
specifice, foarte utile în manipularea datelor. În acelaşi timp cursorul va fi 
localizat pe calculatorul client, evitând astfel supraaglomerarea server-ului în 
aplicaţiile cu mulţi utilizatori concurenţi 
O0bjConnection.CursorLocation= adUseServer - (valoare implicită) - 
cursorul va fi furnizat de bibliotecile de clase ale driver-ului specific, care este 
posibil să furnizeze doar o parte din funcţionalitatea standard a unui obiect 
Recordset. De asemenea, cursorul va fi creat pe server-ul pe care este 
localizată sursa de date, datele cerute de aplicaţia client (sau actualizările 
efectuate de aceasta din urmă) fiind transmise în mod continuu prin reţea. Ca 
urmare, într-o aplicaţie multiutilizator este posibil să apară momente de 
supraîncărcare a resurselor server-ului şi a reţelei, generând în final creşterea 
timpilor de răspuns. Acest tip de cursor este indicat a fi utilizat doar în cazul în 
care resursele clientului sunt limitate 


Clasa Recordset. Tehnici specifice de manipulare a datelor. 

După cum s-a văzut şi în exemplul anterior, un obiect Recordset nu este altceva 
decât reprezentarea obiectuală, la nivelul aplicaţiei client, a unui set de date 
(înregistrări) extrase ca urmare a execuţiei unei fraze Select-SQL. În termeni uzuali, 
un obiect Recodset are la bază un cursor, generat de driver. Un cursor prezintă 
datele într-o manieră familiară (linii şi coloane) indiferent de modul de reprezentare 
fizică a acestora la nivelul sursei de date şi oferă diverse modalităţi de manipulare a 
acestora astfel: 

e Pentru un cursor există noţiunea de pointer de linie, sau linie curentă. 
Astfel, la un moment dat putem extrage/modifica datele ce constituie linia 
respectivă 

e Există posibilitatea deplasării de la o linie la alta, înainte şi înapoi 

Un cursor se crează automat la execuţia metodei open() a unui obiect 
Recordset. Semnătura acestei metode este următoarea: 


objRecSet.Open(Source, ActiveConnection, CursorType, LockType) 
unde: 


- Source - va reprezenta comanda Select SQL ce va fi executată la nivelul 
sursei de date (furnizată sub formă de şir de caractere: String) 

-  ActiveConnection - obiectul de tip Connection ce furnizează conexiunea 
fizică la sursa de date. Acest obiect trebuie să furnizeze o conexiune 
activă, în sensul că trebuie să-i fi fost invocată metoda open() înainte de a-l 
trimite acestui parametru (vezi şi exemplul din listingul 4-2). 

Ultimii 2 parametri sunt opționali (dar esentiali) şi necesită câteva lămuriri 
suplimentare. 

Există mai multe tipuri de cursoare: 

-  Cursoare care permit, sau nu, actualizarea datelor 

-  Cursoare care permit deplasarea de la o linie la alta înainte şi înapoi, şi 
cursoare care permit deplasarea doar într-un singur sens (înainte), o 
singură dată 

- Cursoare dinamice şi statice.  Cursoarele dinamice sesizează 
actualizările(insert, update, delete) efectuate de alţi utilizatori asupra sursei 
de date, aceste actualizări devenind imediat disponibile utilizatorului 
cursorului. Cursoarele statice reprezintă o imagine a sursei de date la un 
moment dat în timp (la momentul execuţiei frazei Select-SQL), actualizările 
efectuate de alţi utilizatori fiind disponibile doar prin reinterogarea sursei de 
date. 

După cum se poate intui, tipul cursorului depinde de necesităţile aplicaţiei şi va fi 
stabilit de către programator prin intermediul celui de-al treilea parametru 
(CursorType) la invocarea metodei open()a obiectului Recordset. Există de 
asemenea un atribut (proprietate) cu acelaşi nume (CursorType) ce poate fi utilizat 
pentru un obiect Recordset deja construit. Trebuie avute în vedere totuşi 
următoarele aspecte: 

- cursoarele dinamice sunt mai lente decât cele statice datorită faptului 
că trebuie să menţină o stare conversaţională continuă cu sursa de date 
pentru a afla despre noile actualizări efectuate de alţi utilizatori; 

- este imposibil a se obţine un cursor actualizabil dacă fraza SQL nu extrage 
date dintr-o singură tabelă. În cazul interogărilor ce implică joncțiuni, 
sau clauze de grupare a datelor, se vor obţine întotdeauna 
cursoare neactualizabile. 

Valoari valide pentru parametrul CursorType al metodei open() sau atributul cu 
acelaşi nume al unui obiect Recordset vor fi constantele definite în acest sens de 
ADO, după cum urmează: 


adOpenStatic | Modificările executate de alt utilizator nu vor fi disponibile. 


Avantajul acestui tip de cursor constă în viteza sporită de procesare 


a operaţiilor de citire/scriere a setului de date obţinut de la sursa de 
date 


adOpenForwar | -setare implicită - cursorul poate fi parcurs o singură dată, într-un 
dOnly singur sens (de “sus” în “jos”) . Operaţiunea de parcurgere a 
acestui cursor (cu metoda moveNext() a obiectului Recordset ) este 
foarte rapidă 


adOpenDynam | Actualizările efectuate de alţi utilizatori (clienţi ai BD) sunt imediat 
[e disponibile la nivelul obiectului RecordSet curent. Este cel mai lent 
tip de cursor având în vedere faptul că trebuie să identifice în timp 
real ( trebuie să verifice continuu sursa de date) actualizările 
(Update, Insert,Delete) efectuate de alţi utilizatori ai bazei de date 


adOpenkKeySet | Defineşte un cursor aproape identic cu adOpenDynamic doar că 
înregistrările noi (ale altor utilizatori) nu sunt disponibile la nivelul 
obiectului Recordset curent. Pentru a obţine noile înregistrări va fi 
necesara reinvocarea metodei open() sau requery() ( se va 


reinteroga sursa de date ) . Acesta este tipul de cursor 
recomandabil a se utiliza pentru a obține o aplicaţie suficient de 
“sensitivă”. 


Tehnici de propagare a actualizărilor către sursa de date 


Când vorbim despre aplicaţii multiutilizator este esenţial să conştientizăm faptul 
că serverul care găzduieşte sursa de date (SGBD-ul) trebuie să gestioneze cumva 
accesul concurenţial la date. În majoritatea situaţiilor se vorbeşte de un proces 
denumit locking (blocaj). Prin blocaj înţelegem procesul prin care SGBD-ul 
restricţionează accesul la o anumită înregistrare într-un mediu multiutilizator. Atunci 
când o înregistrare sau o coloană este blocat exclusiv de un anumit utilizator, alţi 
utilizatori nu vor avea acces concurent la datele respectivei linii sau coloane până 
când blocajul nu este înlăturat. Prin această tehnică SGBD-ul asigură menţinerea 
consistenţei datelor: doi utilizatori nu pot modifica simultan aceleaşi date (vezi şi 
figura 4-8). 

Tehnicile de blocare trebuie alese cu grijă datorită impactului imediat pe care îl 
au asupra responsivităţii şi flexibilităţii aplicaţiei. În ADO, tipul de blocaj poate fi 
stabilit prin intermediul proprietății LockType a unui obiect RecordSet sau al 
parametrului corespunzător al metodei open). 

Important! Proprietatea LockType este read-only dacă Recordset-ul este 
deschis. Poate fi modificată numai dacă respectivul cursor este închis ( cu metoda 


close()). De cele mai multe ori se utilizează însă parametrul corespunzător al 
metodei open(). 


„Stella Artois 
CD-RW 

i Poiana Negri 

„Imprimanta HP-1300 i... 


Poiana Negi 
„Imprimanta HP-1300 50! 


Aplicatie dient 1 Aplicatie client 2 


Figura 4-8 Specificul aplicaţiilor multiutilizator : doi utilizatori pot încerca sa modifice aceeaşi 
înregistrare în acelaşi timp 

Pentru a furniza valori valide parametrului sau proprietăţii LockType, vom recurge 
la câteva constante definite de ADO în acest sens: 

AdLockBatchOptimistic - pentru prelucrarea pe loturi : toate actualizările 
(Insert, Update, Delete) vor fi efectuate doar la nivelul Recordset-ului , urmând a fi 
propagate toate de-odată cu metoda updateBacth() sau anulate cu metoda 
cancelBatch(). Blocajele la nivelul sursei de date se vor realiza doar în momentul în 
care se trimit actualizările spre server. Această tehnică este deosebit de utilă pentru 
aplicaţiile în care costurile traficului în reţea sunt ridicate (fie ca preţ fie ca şi 
necesar de resurse sau timp) deoarece, o dată obţinut setul de date, clientul poate 
închide conexiunea şi o va redeschide chiar înainte de execuţia metodei 
updateBatch(). Probleme vor apare doar în sistemele în care este necesar a se 
asigura disponibilitatea imediată a tuturor actualizărilor efectuate de diverşi 
utilizatori. Dacă alţi utilizatori au modificat între timp aceeaşi (aceleaşi) înregistrare 
(înregistrări) ca şi utilizatorul curent, se va obţine un mesaj de eroare prin care 
utilizatorul curent este avertizat că valorile disponibile la nivelul recordsetului curent 
înaintea modificărilor efectuate local, nu mai reflectă realitatea din momentul 
obţinerii setului de date respectiv. Acest tip de cursor este indicat a se utiliza atunci 
când există puţine şanse ca doi utilizatori să modifice concurent aceleaşi date. 


AdLockOptimistic - modificările efectuate pe linia curentă vor fi trimise în sursa 
de date la apelul metodei update() sau la deplasarea pointerului pe o altă linie în 
RecordSet. Actualizările vor fi astfel disponibile imediat în sursa de date. Blocajul 
înregistrării în sursa de date se va efectua doar la momentul trimiterii actualizărilor. 
Ca urmare, este posibil ca, din momentul începerii procesului de editare a datelor şi 
pînă la “comiterea” modificărilor în sursa de date, alţi utilizatori să modifice aceeaşi 
înregistrare. În acest caz se va obţine un mesaj de eroare prin care se specifică 
neconcordanţa vechilor valori (dinaintea modificărilor) cu cele existente în sursa de 
date. Acest tip de cursor este indicat a se utiliza atunci când există puţine şanse ca 
doi utilizatori să modifice concurent aceleaşi date. 

AdLockPessimistic - chiar în momentul dinaintea inceperii editării unei linii din 
Recordset se încearcă blocarea respectivei înregistrări la nivelul sursei de date, 
astfel încât alţi utilizatori nu vor putea modifica aceleaşi date până când modificările 
primului utilizator (cel care a obţinut acces exclusiv) nu sunt permanentizate 
(metoda update() sau deplasarea pointerului -ex: moveNext()) sau anulate (metoda 
cancelUpdate()). Acest tip de cursor este indicat a se utiliza atunci când mai multi 
utilizatori pot modifica în mod concurent aceleaşi date. Unele drivere (spre exemplu 
driver-ul VFP) nu implementează acest tip de cursor dar nici nu produc o eroare 
specifică atunci când se utilizează aceasta valoare pentru parametrul sau 
proprietatea LockType. De obicei, aceste drivere vor selecta în mod implicit tipul 
adLockOptimistic chiar dacă programatorul specifică explicit adLockPessimistic. 


Principalele metode de manipulare a datelor definite de clasa RecordSet 
sunt următoarele: 

e moveNext(), movePrevious(), moveFirst(), MoveLast() - mute pointerul de 
linie curenta în RecordSet. Dacă au fost efectuate modificări pe linia curentă, 
invocarea oricăreia din cele patru metode va determina implicit trimiterea 
modificărilor în sursa de date numai dacă tehnica de blocare a înregistrărilor 
este: adLockOptimistic. (vezi comentariile de mai jos relativ la diversele tehnici 
de blocare a înregistrărilor). Pentru a testa dacă mai sunt linii înaintea sau după 
locaţia curentă a pointerului, există două proprietăţi ce pot fi interogate: 

o objRset.EOF - va returna valoarea true dacă a fost depăşită ultima 
iregistrare (prin deplasare înainte) 

o objRset.BOF - va returna valoarea true dacă a fost depăşită prima 
înregistrare (prin deplasare înapoi) 


e cancelUpdate() - anuleaza modificările efectuate pe linia curentă (sau anuleaza 
înregistrarea nouă) la nivelul obiectului RecordSet, restaurând valorile iniţiale 
pentru câmpurile modificate. 

e update() - trimite în sursa de date modificările efectuate în RecorasSet pe linia 
curentă. Poate genera erori dacă sunt încălcate diverse restricţii la nivelul sursei 
de date. De aceea este bine ca aceste erori să fie interceptate după tehnica 
standard VB de interceptare a erorilor, pentru a nu se bloca aplicaţia. Spre 
exemplu: 


On Error GoTo erori: 


Dim adoConnection As ADODB.Connection 
Dim adoRsetPersonal As ADODB.Recordset 
Dim frazaSQL As String 
Set adoConnection = New ADODB.Connection 
Set adoRsetPersonal = New ADODB.Recordset 
adoConnection.CursorLocation = aduseClient 
adoConnection.Open ("ConexiuneVvFP") 
'-- interogarea bazei -- 
frazaSQL = "select * from personal " 'where compart='FIN' order by numepren" 
Call adoRsetPersonal.Open(frazaSQL, adoConnection, adOpenkKeyset, adLockOptimistic) 
adoRsetPersonaT. MoveFirst 
'-- modificam prima inregistrare — 
adoRsetPersonal.Fields("'marca") = 
adoRsetPersonal.Fields("salorar") 
( 
( 


adoRsetPersonal.Fields("salorarco") = 300000 
adoRsetPersonal.Fields("datasv") = 412/22/20024 


30 
) 


'—-propagam modificarile catre sursa de date —- 
adoRsetPersonal.Update 
'—-sau anulam modificarile: -— 


' adoRsetPersonal. CanceluUpdate 


adoRsetPersonal.close 
adoConnection.close 


Exit Sub 


erori: 
adoRsetPersonal.close 
adoConnection.close 


MsgBox Err.Number & " " & Err.Source & " " & Err.Description 
'-- vezi mai jos listingul 4-3 pentru o alta modalitate (specifica ADO) de tratare a erorilor 


End Sub 
e UpdateBatch() - specifică tehnicii de actualizare pe loturi (vezi secţiunea 


următoare referitoare la tehnici de propagare a actualizărilor) - trimite spre sursa 


de date actualizările efectuate la nivelul RecordSet-ului în ultima sesiune (de la 
ultimul apel al aceleiaşi metode sau al metodei cancelBach()). 

e CancelBatch() - specifică tehnicii de actualizare pe loturi (vezi comentariile 
referitoare la tehnicile de actualizare de mai jos) - anulează actualizările 
efectuate la nivelul RecordSet-ului în ultima sesiune (de la ultimul apel al 
aceleiaşi metode sau al metodei updateBach()). 

e Resync() - “reîmprospătează” setul de date al obiectului Recordset curent cu 
valorile actuale existente în sursa de date. Această metodă se utilizează de obicei 
pentru a obţine varianta actualizată a setului de date în condiţiile unei aplicaţii în 
care mai mulţi utilizatori modifică în mod concurent acelaşi set de date. De 
remarcat că această metodă nu va reexecuta comanda SQL ce stă la baza 
formării RecordSet-ului. Ca urmare a execuţiei acestei metode pot apare 
următoarele situaţii: 

o Noile înregistrări (adăugate de alţi utilizatori) nu vor fi vizibile la 
nivelul obiectului Recordset curent 

o Dacă o înregistrare a fost ştearsă de un alt utilizator se va obţine o 
eroare (eroare ce trebuie tratată - vezi exemplele de mai jos) 

o Dacă alţi utilizatori au modificat înregistrări aferente setului curent de 
date, respectivele modificări vor fi vizibile 

e Requeryl() - reexecută fraza SQL ce stă la baza Recordset-ului (fraza cu care a 
fost invocată metoda open()) şi reîmprospătează datele obiectului Recordset 
curent, toate actualizările efectuate de alţi utilizatori (Insert, Update, Delete) fiind 
imediat disponibile. Execuţia acestei metode este echivalentă cu execuţia 
metodei close() şi din nou a metodei open(). 

e AddNew (Fields ,Values) - Adauga o noua înregistrare în RecordSet şi se 
pozitioneaza pe ea, urmând a fi specificate valorile pentru fiecare atribut. Pentru 
a se realiza efectiv Insert-ul în sursa de date se utilizează apoi metoda update (). 
Parametrii sunt opţionali, pot fi utilizaţi doar împreună (se poate face analogia cu 
o fraza SQL: Insert into tabela (lista atribute) values (lista 
valori)) şi specifică: 

Fields - un vector cu denumirile câmpurilor 
Values - un vector cu valori pentru câmpurile specificate prin 
parametrul Fields. Valorie trebuie bineinţeles specificate conform 
ordinii câmpurilor 
Dacă se utilizează cei doi parametri, noua înregistrare va fi imediat inserată în 
tabela-sursă, fără a mai fi necesară invocarea metodei update). 


Deşi există şi posibilitatea utilizării metodei execute() a unui obiect Connection, 
pentru a insera o înregistrare nouă, avantajul utilizării metodei AddNew () este acela 
că noua înregistrare devine imediat disponibilă la nivelul obiectului Recordset. 

e Delete - şterge înregistrarea curentă din obiectul RecordSet. Înregistrarea va fi 
ştearsă: o dată ce pointerul de linie se repoziţionează. 

e Find(criteriu) - execută o căutare, la nivelul setului de date al obiectului 
RecordSet, şi poziţionează pointerul de linie curentă pe prima linie ce 
îndeplineşte condiţia. Dacă nu este găsită nici o înregistrare care sa 
îndeplinească condiţia, poziţia curenta va fi EOF. Parametrul criteriu va fi un şir 


de caractere furnizat sub forma: câmp=valoare. Spre exemplu 


ObjRSet .moveFirst 
ObjRSet. find(“marca=1009”) 
ObjRSet. find(“numepren='Costel” ”) 
If ObjRSet.EOF then 
MsgBox („nu a fost gasita nici o inreg care sa indeplineasca ultimul criteriu”) 
End If 


Sau 


ObjRSet .moveFirst 

Dim cheie as String 
Cheie="Costel” 

ObjRSet. find(“numepren=” & cheie) 


Important! Metoda find() defineşte şi un al doilea parametru, opţional totuşi, prin 
care se specifică direcţia de căutare (înainte sau înapoi) relativ la poziţia curentă a 
pointerului de linie. Pentru a nu identifica explicit direcţia de căutare, este mai 
simplu să poziţionăm mai întâi pointer-ul de linie pe prima linie din Recordset. 

lată în continuare câteva exemple de manipulare a datelor prin intermediul unui 
obiect RecordSet. 

Primul exemplu - actualizarea tabelei Personal (structura este cea definita la 
laboratorul BD1) prin: modificarea primei înregistrări, ştergerea celei de-a doua şi 
adăugarea unei înregistrări noi. 

Notă. A se observa şi modalitatea de tratare a erorirlor (prentu detalii despre 
colecţia Errors vezi secţiunea Modelul Obiectual ADO) 

Listing 4-3 Actualizări prin intermediul unui Recordset de tip adLockOptimistic 
Sub testupdatel() 


On Error GoTo erori: 


Dim objConn As New ADODB.Connection 
Dim objRset As New ADODB.Recordset 


'-- deschiderea conexiunii - - 
objConn.CursorLocation = aduseClient 
objConn.Open ("ConexiuneVFP") 


4 în cazul specific VisualFoxPro, ştergerea presupune doar marcarea pentru ştergere la nivelul sursei de date! Înregistrările 
nu vor putea fi şterse definitiv din VB (nu poate fi executată comanda Fox - > Pack) . 


1-- incarcarea recordset-ului 
objRset.Open "select * from personal", objConn, adOpenStatic, adLockOptimistic 


'-- modificam prima inregistrare -- 

objRset .MoveFirst 

objRset.Fields("Numepren") = "ANGAJAT MODIFICAT" 
objRset.Fields("'salorar") = 0 
objRset.Fields("salorarco") = 300000 
objRset.Fields("datasv") = 412/22/20024 


'pentru ca Recordset-ul este de tip adLockOptimistic, 
'repozitionarea pointer-ului va fi echivalenta cu objRset.Update 


'-- stergem a doua inregistrare (pe care tocmai ne-am pozitionat 
objRset.Delete 


'—-nici acum nu este obligatoriu objRset.Update pentru ca 
'--la urmatoarea repozitionare (objRset.AddNew) se va trimite automat actualizarea 


1-- adaugam o noua inregistrare: 


objRset.Fields("Numepren") = "ANGAJAT NOU" 
objRset.Fields("'compart") = "FIN" 
objRset.Fields('"'salorar") = 0 
objRset.Fields("salorarco") = 300000 
objRset.Fields("datasv") = 412/22/20024 
objRset.Fields("colaborator") = True 


'-- trimitem explicit in BD: (este necesar Update pentru ca nu mai repozitionanm pointer-ul) 
objRset.Update 
objConn. close 
Exit Sub 
1—-blocul de tratare erori-- 
erori: 
objRset.close 
objConn.close 


If objConn.Errors.Count <> © Then 


For i = 0 To objConn.Errors.Count - 1 
MsgBox objConn.Errors(i).Number 


& " " & objConn.Errors(i).Source _ 
&" " & objConn.Errors(i).Description 
Next 
Else ' este vorba de o eroare VB si nu ADO 
MsgBox Err.Number & " " & Err.Source & " " & Err.Description, "Eroare" 
End If 


End Sub 


Pentru a înţelege în mod corect funcţionalitatea Recordset-urilor de tip 
adLockOptimistic, la testarea procedurii din listing-ul de mai sus este indicat să 
procedaţi astfel: 

- Deschideţi baza de date VFP (din mediul VFP) în mod “Shared” . lată 
secvenţa de comenzi VFP : 

Close all 

open data salariibd shared 
use personal in O shared 
brow 

-  Marcaţi cu puncte “breakPoint” liniile de cod evidenţiate în listing cu o 
culoare diferita (breakpoint > click pe bara din stanga a editorului VB > la 
acel pas programul îşi va suspenda execuţia şi va putea fi ulterior reluat 
prin butonul “continue”) 

- La momentul în care procedura se suspendă, verificaţi valorile din VFP 
(eventual executaţi din nou o comanda Browse pentru a fi siguri că din VFP 
vizualizaţi ultima variantă a tabelei) 

- Apoi reluaţi execuţia procedurii din VB şi, la următoarea suspendare, 
verificaţi din nou valorile din tabela VFP 


Al doilea exemplu va executa aceleaşi operaţii de actualizare doar că apelând la 
tehnica  prelucărilor pe loturi - prin intermediul unui obiect Recordset de tip 
adLockBatchoptimistic. În acest caz toate actualizările vor deveni 
disponibile la nivelul sursei (VFP) doar la execuţia metodei 
updateBatch(). Pentru testare procedaţi în mod similar exemplului precedent 


Listing 4-4 Actualizări prin intermediul unui Recordset de tip adLockBatchOptimistic 
Sub testUpdateBatch() 


On Error GoTo erori: 


Dim objConn As New ADODB.Connection 
Dim objRset As New ADODB.Recordset 


'-- deschiderea conexiunii - - 
objConn.CursorLocation = aduUseClient 


objConn.Open ("ConexiuneVFP") 


'-- incarcarea recordset-ului 
objRset.Open "select * from personal", objConn, adOpenStatic, adLockBatchoptimistic 
MsgBox ("y") 


'-- modificam prima inregistrare -- 
objRset.MoveFirst 
objRset.Fields("Numepren") = "MODIFICAT 2" 
objRset.Fields("salorar") = 100 
objRset.Fields("salorarco") = 1000 


objRset.Fields("datasv") = 410/22/200274 
'pentru ca e adLockBatchOptimistic, 
"repozitionarea pointer-ului nu va trimite actualizarile in bd 


objRset .MoveLast 


'-- stergem a ultima inregistrare 
objRset.Delete 


'-- adaugam o noua inregistrare: 
objRset.AddNew 
objRset.Fields("marca") = 6003 
objRset.Fields("Numepren") = "ANGAJAT NOU 2" 
objRset.Fields("'compart") = "FIN" 
objRset.Fields('"'salorar") = 0 
objRset.Fields("salorarco") = 0 
objRset.Fields("datasv") = 412/22/20024 
objRset.Fields("colaborator") = False 


'-- trimitem explicit toate cele trei actualizarile in BD: 
objRset.close 

objConn. close 

Exit Sub 

erori: 


objRset.close 
obj Conn. close 


If objConn.Errors.Count <> 0 Then 


For i = 0 To objConn.Errors.Count - 1 
MsgBox objConn.Errors(i).Number 


& " " & objConn.Errors(i).Source _ 
&" " & objConn.Errors(i).Description 
Next 
Else ' este vorba de o eroare VB si nu ADO 
MsgBox Err.Number & " " & Err.Source & " " & Err.Description, "Eroare" 
End If 
End Sub 


Clasa Command. Comenzi (SQL sau non-SQL) parametrizate 
Proprietati 
e  commandText - va conţine comanda ce va fi executată. Comanda poate fi 


parametrizată prin utilizarea semnului “?”. Spre exemplu: 


objCmd.commandText="Select * from personal” 
sau 


objCmd.commandText="Personal” 
sau o comandă parametrizată: 


objCmd.commandText="Select * from personal where compart=? And colaborator=?” 
e commandType - specifică tipul comenzii. Valoarea va fi furnizată sub forma 


uneia din constantele definite în acest sens: 


= adCmdText - atunci când prin intermediul proprietăţii 
commandText se furnizează o comandă (de orice tip - SQL sau 
non-SQL) 

= adCmdTable - dacă se doreşte obţinerea unui RecordSet cu 
toate înregistrările unei tabele - în acest caz proprietatea 
commandText va specifica numele unei tabele 

= adCmdStoredProc - dacă pentru proprietatea CommandText se 
specifică numele unei proceduri stocate ce se doreşte a se 
executa.  Precizăm că unele drivere (spre exemplu 
VisualFoxPro) nu suportă deocamdată execuţia directă a unei 
proceduri stocate, fiind necesar un artificiu, după cum vom 
vedea în cele ce urmează 

e activeConnection - acestei proprietăţi trebuie să i se atribuie un obiect 
Connection valid prin intermediul căruia se va realiza trimiterea spre 
execuţie a comenzii şi preluarea setului de rezultate 

e prepared - de tip Boolean - dacă are valoarea true comanda va fi 
precompilată pe server, astfel încât execuțiile repetate ale acesteia vor fi 
deosebit de rapide. Se utilizează în cazul comenzilor parametrizate (vezi 
exemplul de mai jos) 

e Parameters - colecţie de obiecte Parameter ce vor furniza valori în cazul 
unor comenzi parametrizate (vezi exemplul de mai jos) . Această colecţie 
defineşte două metode esenţiale: 

o Append (objParameter) - adaugă în colecţie un obiect Parameter 
(vezi şi metoda createParameter) 

o Delete (index / nume) - şterge din colecţie obiectul identificat prin 
poziţie sau nume 

Pentru a extrage/modifica valoarea unuia din parametri utilizăm tehnica specifică 
pentru colecţii: 
Valoare= 0bjCmd.Parameters(“numeParam”) sau 
Valoare= 0bjCmd.Parameters(indexParam) 


Sau, pentru modificarea valorii parametrului: 
0bj Cmd. Parameters (“numeparametru” )=valNoua 


Metodele clasei : 


e CreateParameter (Name, Type, Direction, Size, Value) - 
construieşte un obiect Parameter ce va fi apoi introdus în colecţia 
Parameters (proprietate a unui obiect Command). Parametrii acestei 
metode sunt cu toţii opționali şi au următoarele semnificaţii: 

o Name - numele parametrului 

o Type - tipul de dată al acestuia (există o serie de constante pentru 
fiecare tip de dată, spre exemplu: adChar, adDate, adDouble, etc..) 

o Direction - dacă este de intrare sau este vorba de rezultatul 
returnat de o funcţie (există de asemenea constante definite în acest 
sens: adParamInput - pentru parametrii de intrare; 
adParamReturnValue - dacă respectivul parametru va prelua 
rezultatul execuției unei funcții) 

o Size -lungimea 

o Value - o valoare pentru respectivul parametru. Ulterior construirii 
obiectului Parameter, dacă dorim să furnizăm altă valoare vom utiliza 
proprietatea value 

e Execute(RecordsAffected, Parameters) - execută comanda (precizată 
de proprietarea commandText) la nivelul sursei de date . Va genera un 
obiect RecordSet dacă respectiva comandă este un Select-SQL sau este o 


tabelă. 
o RecordsAffected - are aceeaşi semnificaţie ca şi în cazul obiectelor 
Connection. 
o Parameters - va reprezenta un vectori cu valori pentru fiecare 


parametru al unei comenzi parametrizate. Spre exemplu: 


objCmd.commandText="Select * from personal where compart=? And colaborator=?” 
DIM valori(1) 

Valori(0)="FIN” 

Valori(1)=true 


Set objRset= ObjCmd.execute( , valori) * pentru primul argument al metodei nu este obligatoriu sa furnizam o 
variabila 
“dar utilizam virgula 


Exemplele următoare construiesc o frază SQL - Select parametrizată pentru a 
extrage un subset de înregistrări din tabela Personal (structura tabelei este cea 
descrisă la laboratorul BD1). 

Primul exemplu va utiliza obiecte Parameter (vezi comentariile introduse in 
secvenţa de cod). 


Exemplul 1: SQL parametrizat cu obiecte Parameter 
Sub testSQlLParametrizat() 


Dim adoConnection As ADODB.Connection 
Dim adoRsetPersonal As ADODB.Recordset 
Dim cmd As ADODB. Command 

Dim param As ADODB.Parameter 


1-- crearea noului obiect Connection -- 
Set adoConnection = New ADODB.Connection 


1-- deschiderea conexiunii -- 
adoConnection.CursorLocation = aduseClient 
adoConnection.Open ("ConexiuneVvFP") 


Set cmd = New ADODB. Command 

cmd.ActiveConnection = adoConnection 

cmd . CommandType = adCmdText 

cmd. CommandText "select * from personal where compart=? and colaborator=?" 


'-- determinam driverul sa compileze fraza la nivelul SGBD-ului 
cmd.Prepared = True 


'-- construim doua obiecte Parameter pentru cei doi parametri ai frazei SQL 
1-- si apoi adaugam in colectia Parameters 
1--(latentie --> ordinea lor in colectie este esentiala) 
Set param = cmd.CreateParameter("compartID", adChar, adParamInput, 6, "FIN") 
cmd. Parameters .Append param 
Set param = cmd.CreateParameter("colab", adBoolean, adParamInput, , True) 
cmd. Parameters .Append param 
'--executam comanda SQL si preluam Recordset-ul returnat in variabila adoRsetPersonal 
Set adoRsetPersonal = cmd.Execute() 
Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("marca") & " " & adoRsetPersonal.Fields("numepren") _ 


& " " 6 adoRsetPersonal.Fields("datasv") & " " & adoRsetPersonal.Fields("compart")) 


adoRsetPersonal.MoveNext 


Loop 


Debug.Print ("------------- Noul set de date dupa modificarea parametrilor------------------ ") 
'modificam valoarea unuia din parametri (sau a tuturor parametrilor daca trebuie) 
cmd.Parameters("'compartID'') = "CONTA" 


'reexecutam comanda SQL ce sta la baza Recordset-ului nostru (prin metoda Requery) 
1 --> vom obtine colaboratorii (colab=true) din compartimentul CONTA 


adoRsetPersonatl.Regquery 
Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("marca") & " " & adoRsetPersonal.Fields("numepren") _ 
& " " 6 adoRsetPersonal.Fields("datasv") & " " & adoRsetPersonal.Fields("compart")) 


adoRsetPersonal.MoveNext 


Loop 


End Sub 


Avantajul utilizării obiectelor Prameter este acela că, o dată obţinut primul obiect 
Recordset, se poate invoca metoda Requery() pentru a reîncărca datele conform 
noilor valori ale parametrilor. Ca urmare, acelaşi obiect Recordset poate fi utilizat 
de aplicaţie pentru a manipula un subset de date sau altul 

În continuare prezentăm şi varianta de program fără utilizarea obiectelor 
Parameter. 


Exemplul 2: SQL parametrizat fără obiecte Parameter 
Sub testSQLParametrizat2 () 


Dim adoConnection As ADODB.Connection 
Dim adoRsetPersonal As ADODB.Recordset 
Dim cmd As ADODB. Command 

Dim param As ADODB.Parameter 


'-- crearea noului obiect Connection -- 
Set adoConnection = New ADODB.Connection 


1-- deschiderea conexiunii -- 
adoConnection.CursorLocation = aduseClient 
adoConnection.Open ("ConexiuneVvFP") 


Set cmd = New ADODB. Command 

cmd.ActiveConnection = adoConnection 

cmd . CommandType = adCmdText 

cmd. CommandText = "select * from personal where compart=? and colaborator=?" 


'-- determinam driverul sa compileze fraza la nivelul SGBD-ului 
cmd.Prepared = True 


'-- construim un vector cu doua elemente ce vor constitui valorile celor doi parametri ai 
frazei SQL 
1--(latentie --> ordinea elementelor in vector este esentiala) 


Dim valori(1 To 2) 
valori(1) = "FIN" 
valori(2) = True 


'-- invocam metoda execute cu vectorul "valori" furnizat ca al doilea parametru 
Set adoRsetPersonal = cmd.Execute(, valori) 


'adoRsetPersonal.Close 
'adoRsetPersonatl.CursorType = adOpenkKeyset 
'adoRsetPersonal.LockType = adLockOptimistic 


'adoRsetPersonal.Open 


Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("marca") & " " & adoRsetPersonal.Fields("numepren") _ 
& " "1 &  adoRsetPersonal.Fields('"'datasv') & " " & 
adoRsetPersonal.Fields("compart")) 
' adoRsetPersonal.Fields('"'salorar") = 0 
adoRsetPersonal.MoveNext 


Loop 


Debug.Print ("------------- Noul set de date dupa modificarea 
parametrilor----------------------- ") 


'modificam valoarea unuia din parametri (sau a tuturor parametrilor daca trebuie) 
valori(1) = "CONTA" 


'reexecutam fraza SQL --> vom obtine un nou obiect Recordset cu toti 
' colaboratorii din compartimentul CONTA 
Set adoRsetPersonal = cmd.Execute(, valori) 


Do While Not adoRsetPersonal.E0F 
Debug.Print (adoRsetPersonal.Fields("marca") & " " & adoRsetPersonal.Fields("numepren") _ 
& " " 6  adoRsetPersonal.Fields("datasv') & " " & 
adoRsetPersonal.Fields("compart")) 
adoRsetPersonal .MoveNext 


Loop 


End Sub 


Singura diferenţă, vizibilă în acest exemplu faţă de primul, constă în faptul că 
întotdeauna se va apela metoda Execute() a obiectului Command pentru a obţine un 
alt subset de date (conform altor valori ale parametrilor), metodă care întotdeauna 
va returna un obiect Recordset nou. Deşi acest aspect nu pare la prima vedere de o 
importanţă prea mare, lucrurile se schimbă in cazul în care dorim ca setul de date 
obţinut la (obiectul Recordset) să fie actualizabil. 

Astfel, întotdeauna, execuția unei fraze SQL-Select prin intermediul metodei 
Execute() a unui obiect Command va returna un obiect Recordset read-only. Pentru a 
determina Recordset-ul să devină actualizabil va trebui să modificăm valorile a două 
atribute : CursorType şi LockType (vezi secţiunea dedicată obiectelor RecordSet). 
Problema este că aceste proprietăţi pot fi modificate numai dacă setul de date este 
închis. Ca urmare vom fi forţaţi să procedăm la închiderea Recordset-ului obţinut 
(metoda close()), modificarea celor două proprietăţi în conformitate cu necesităţile 
de prelucrare şi apoi redeschiderea Recordset-ului (metoda open(). Astfel 


(presupunem că prelucrările se vor efectua pe loturi): 


Set recSet=objCmd.execute() 

RecSet.close() 

recSetPontaje.CursorType = adOpenStatic 
recSetPontaje.LockType = adLockBatchOptimistic 
RecSet.open() 


Acum, diferenţa între cele două exemple trebuie văzută astfel: 
- pentru primul exemplu este sufucient ca operaţia de mai sus să se execute 
o singură dată (după prima execuţie a metodei Execute()), având în vedere 
că pentru a reîncărca un alt set de date (conform valorilor modificate ale 
parametrilor) utilizăm metoda requery() a obiectului Recordset, metodă 
care nu închide setul de date şi nici nu produce un alt obiect Recordset. Ca 


urmare, proprietăţile respective (CursorType şi LockType) îşi vor păstra 
valorile - cursorul va fi actualizabil. 

pentru cel de-al doilea exemplu operaţia de 
închidere/modificareproprietăţi/redeschidere trebuie efectuată de fiecare 
dată după ce obţinem un nou set de date. Cauza este aceea că acest set de 
date constituie un obiect Recordset complet nou (ca urmare a execuţiei 
metodei Execute() a obiectului Command), obiect care bineînţeles că va fi 
construit în mod similar primului (cu proprietăţile setate pe valorile implicite 
ce nu permit modificarea setului de date) 


